Eclipse Community Forums: Virgo » Bundles inside plans are started concurrently, causing problems

Home » Eclipse Projects » Virgo » Bundles inside plans are started concurrently, causing problems

Bundles inside plans are started concurrently, causing problems [message #1132702]

Fri, 11 October 2013 06:34

Eclipse User

Hey guys,

I am currently facing an issue that hit me several times over the last couple months with various versions of Virgo (3.0, 3.5 and 3.6). "Unfortunately", the problem always miraculously resolved itself somehow, so I did not have the time for a deeper investigation. Here is my "setup":
* a large number of (Spring-powered) bundles in the repository/usr directory
* some plans in the repository/usr directory (plans are atomic, not scoped)
* one "master" plan in the pickup directory (again, atomic, not scoped)

The master plan is referencing the other plans in the repository/usr directory in a specific order and inside each plans the bundles are also sorted due to interdependencies. What I observe now is the following: resolving the plans and the bundles inside them happens in the expected order (as stated in the plan). However, the startup of the Spring contexts in the bundles is done concurrently (I see a number of different "start-signalling-" threads printing out log messages), which leads to problems, because some contexts are powered up faster than others and the interdependencies sometimes cause problems - but not in the terms of "timeout waiting for service" etc, but in terms of really strange exceptions (like ClassNotFoundExceptions of classes inside the same package they are referenced etc.). If I deploy the bundles manually one by one in the order I initially specified in the plans and wait with the deployment of the next bundle until the previous bundle's Spring context is fully started, everything works like a charm.

To sum it up, I'd like to know if there is a way to "force" Virgo to skip concurrent execution of Spring context initialization or if my setup is just screwed and I need to think it over.

Thanks in advance

Sven

[Updated on: Fri, 11 October 2013 06:34] by Moderator

Re: Bundles inside plans are started concurrently, causing problems [message #1132720 is a reply to message #1132702]

Fri, 11 October 2013 06:49

Eclipse User

Hi Sven,

there is a directive available for use with the Spring-Context header. Please see the Gemini Blueprint documentation[1] for more details.

create-asynchronously (false|true): controls whether the application context is created asynchronously (the default), or synchronously.

For example:

Spring-Context: *;create-asynchronously:=false

"Creates an application context synchronously, using all of the "*.xml" files contained in the META-INF/spring folder."

Maybe this is what you are looking for...

Regards,
florian

[1] http://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/app-deploy.html

[Updated on: Fri, 11 October 2013 06:52] by Moderator

Re: Bundles inside plans are started concurrently, causing problems [message #1132793 is a reply to message #1132720]

Fri, 11 October 2013 07:46

Eclipse User

Thanks Florian, I'll take a closer look at this manifest entry!

Re: Bundles inside plans are started concurrently, causing problems [message #1132821 is a reply to message #1132793]

Fri, 11 October 2013 08:08

Eclipse User

Another question - is there any chance to specify that sub-plans (i.e. plans referenced from another plan) are started synchronously?

Because I see that the plans are started in order, but plan A is started and once all its bundles are resolved (i.e. the Spring contexts of those bundles are not (fully) started yet), plan B is already started. Once plan A's bundles have all started their contexts, the log contains the message that plan A has been started (so the framework monitors the context creation of the bundles). My case would be easily resolved if starting plans would happen synchronously, because the problem arises due to inter-plan dependencies...

Re: Bundles inside plans are started concurrently, causing problems [message #1133070 is a reply to message #1132821]

Fri, 11 October 2013 11:39

Eclipse User

The plan start logic allows asynchronous initialisation of the members of the plan, be they bundles or other plans. The aim is to maximise concurrency.

However, when a plan is deployed, it (and any nested plans and all their bundles) are resolved before any of them are started. So if all the bundles are "normal" OSGi bundles, class loading errors should not occur as all the class loading delegation paths have been established during resolution. Dynamic imports and DIY custom class loading can result in class loading errors. If you are not doing any of that, then it would be good to dig into why the class loading errors are happening. If you can reproduce the problem in a debugger, it's not too bad to step through the class loading logic and find the root cause. Wink

Previous Topic:	Spring Context created in multiple threads?
Next Topic:	Example of a custom {ContextPath}.xml file

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jul 22 19:36:02 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter