Multithreading in OSGi

[Bulu <bu...@romandie.com>]

Dear all

My bundles need to use diverse threads to do their work (Timers, 
Workers, Events). And they need to clean them up on stop().

I have found this article 
(http://www.drdobbs.com/jvm/multithreading-java-osgi/191601642) which 
addresses the problem by using a Thread management class in each bundle, 
which keeps track of all threads and knows how to stop them when the 
bundle is stopping. It's a nice approach, but it's from 2006 and doesn't 
use Executors etc.

Also, my threads will work accross bundles - simplest example is the 
whiteboard pattern, which calls code in any registered listener, in any 
bundle.

Is the approach in this article the right way to go, to handle 
multithreading in OSGi? (ie. do you use it?)
Are there other recommended approaches & best practices on how to manage 
(start, stop, share) multiple threads in OSGi?
To avoid most of the synchronization, I will favor having only 1 main 
worker thread, where each client can submit tasks to perform 
(ExecutorService with a single thread). Is there a recommended OSGi 
approach for sharing this resource?

Thanks
   Philipp





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Multithreading in OSGi

[Frank Lyaruu <fl...@gmail.com>]

Just my two cents:

OGSi doesn't really deal with multithreading, and it works as good (or bad)
as any other java application.
However if you want to be fully dynamic, as in that any bundle can
disappear and reappear at any given time, it is hard to get right.

For a recent project I made extensive use of OSGi events, and that worked
quite well for me: Some thread posts an event, using the EventAdmin, and
other bundles (or the same one) can listen to these events (using an
EventHandler) and perhaps fire other events.

This avoids manual threading altogether, you use the thread pool of the
event manager  and works quite well for some use cases, perhaps yours. It
might require a hefty code refactoring, though.

An explanation of using the EventAdmin:

http://felix.apache.org/site/apache-felix-event-admin.html

I guess the 'DrDobb' approach works fine, but I'd only use it as a last
resort.

regards, Frank


On Tue, Sep 2, 2014 at 11:55 AM, Bulu <bu...@romandie.com> wrote:

> Dear all
>
> My bundles need to use diverse threads to do their work (Timers, Workers,
> Events). And they need to clean them up on stop().
>
> I have found this article (http://www.drdobbs.com/jvm/
> multithreading-java-osgi/191601642) which addresses the problem by using
> a Thread management class in each bundle, which keeps track of all threads
> and knows how to stop them when the bundle is stopping. It's a nice
> approach, but it's from 2006 and doesn't use Executors etc.
>
> Also, my threads will work accross bundles - simplest example is the
> whiteboard pattern, which calls code in any registered listener, in any
> bundle.
>
> Is the approach in this article the right way to go, to handle
> multithreading in OSGi? (ie. do you use it?)
> Are there other recommended approaches & best practices on how to manage
> (start, stop, share) multiple threads in OSGi?
> To avoid most of the synchronization, I will favor having only 1 main
> worker thread, where each client can submit tasks to perform
> (ExecutorService with a single thread). Is there a recommended OSGi
> approach for sharing this resource?
>
> Thanks
>   Philipp
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>