felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Lyaruu <flya...@gmail.com>
Subject Re: Multithreading in OSGi
Date Tue, 02 Sep 2014 19:06:12 GMT
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:


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

regards, Frank

On Tue, Sep 2, 2014 at 11:55 AM, Bulu <bulu@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message