Eclipse Community Forums: Equinox » Concurrent activation of bundles at framework startup?

Help

Home

Home » Eclipse Projects » Equinox » Concurrent activation of bundles at framework startup?

Show: Today's Messages :: Show Polls :: Message Navigator

Concurrent activation of bundles at framework startup? [message #662101]

Tue, 29 March 2011 10:16

Caspar D.

Messages: 35
Registered: July 2009

Member

Is it possible to have bundles activated in concurrent threads,
at framework startup?

A little debugging through the startup logic gives me the impression
that this isn't possible; i.e. that the plugins are activated one
by one sequentially, in a single thread.

But isn't this highly limiting? Why not allow bundles to be activated
in parallel, dependencies permitting?

Thanks
--
Caspar

Report message to a moderator

Re: Concurrent activation of bundles at framework startup? [message #662119 is a reply to message #662101]

Tue, 29 March 2011 12:47

Thomas Watson

Messages: 503
Registered: July 2009

Senior Member

There is no restriction on the number of threads that can be used to call Bundle.start. But the start-level service implementation currently only uses a single thread to start all bundles that have their start-level met and are marked for start. The start-level service is what is used to launch the framework and set the start-level to the beginning start-level.

I believe most all frameworks behave this way. Also, it is a best practice to have activators that either start quickly or perform work in a background thread.

Tom.

Report message to a moderator

Re: Concurrent activation of bundles at framework startup? [message #662290 is a reply to message #662119]

Wed, 30 March 2011 06:11

Caspar D.

Messages: 35
Registered: July 2009

Member

> Also, it is a best practice to have activators that either start
> quickly or perform work in a background thread.

Afaics, the start-level service switches the bundle's state to ACTIVE
as soon as the #start method returns, and then fires a
BundleEvent.STARTED. So if the #start method spawned a background
thread for some of the bundle's startup work, and returned before that
background thread finished, any listeners would be misinformed about
the bundle's true state. I'm not sure how that could be the 'best
practice'...

> There is no restriction on the number of threads that can be used to
> call Bundle.start.

Good, but how do I make use of that?

The problem would be solved if BundleHost.startWorker spawned a
separate thread. But if I override that method in a custom bundle
class, I don't see how I can have that custom class instantiated by
the framework. Can I?

Thanks
--
Caspar

Report message to a moderator

Re: Concurrent activation of bundles at framework startup? [message #662380 is a reply to message #662290]

Wed, 30 March 2011 13:06

Thomas Watson

Messages: 503
Registered: July 2009

Senior Member

Bundle.start() must be a synchronous operation according to the OSGi specification. The implementation of Bundle.start() must not return until either the bundle has started successfully or failed to start and throws an exception.

The best practice in OSGi is to actually have no activators to be honest Wink

Instead the OSGi community generally favors using a DI mechanism such as Declarative Services or Blueprint.

The only way you can take advantage of the fact that Bundle.start() can be called by several threads is to use your own bundle which starts the other bundles in your system instead of using start-level service to activate all your bundles.

Tom.

Report message to a moderator

Previous Topic:	Container not finding included class
Next Topic:	Access restriction exception when using JAXB under Java 1.5

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 22:48:02 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter