| Order of bundle installation [message #1262843] |
Mon, 03 March 2014 21:21  |
Eclipse User |
|
|
|
How does Virgo determine what order to install bundles after a restart?
For example, I have two bundles that are being deployed via a JMX connection. The "client" bundle depends on the "core" bundle. So I install the core bundle first, and then the client. Then if I decide to later update the core bundle, it gets assigned a higher bundle ID. When I restart Virgo, it appears to try to install the client bundle first (since it had a lower ID) and since the core bundle is not there yet, the client will fail to install. Is there any way to get Virgo to "rescan" the bundles after all the bundles have been deployed and try again? Is it possible to get my desired outcome without using plans or pars?
|
|
|
|
|
|
|
| Re: Order of bundle installation [message #1270166 is a reply to message #1270150] |
Wed, 12 March 2014 11:36  |
| Eclipse User |
|
|
|
Let me expand on this a bit..
We recently migrated quite a few servlets to be OSGI specked jar's. Some were war's that we had originally been installing into Tomcat. Some were supporting jar's. One in particular was a utility jar that most of our other servlets depended on which is a JNI loading a DLL. Our packaging installs the bundles into Virgo using JMX controls, and every install of the package will update/install updated bundles. We have another package that installs additional servlets/bundles that also depend on this utility jar, which has ruled out solving this with a plan.
The migration followed a few simple steps..
1) Convert to Maven from Ant, including the source tree layout.
2) Modify the Manifest to add in OSGI information, including dependency and provides
3) Add bundle initialization routines if necessary.
In addition to migrating our bundles, we had to create and require some additional 3rd party bundles
supplying supporting tools, including a bundle for the JDBC jars for the database product we use, and
BIRT, AXIS2, Wicket, Spring Security, ...
At first glance (and second too) the port seemed to work very well. Everything in our infrastructure seemed to start and work.
After deploying in the field, and working on the next set of feature enhancements we started running into a few troubling problems.
1) The JNI bundle did not EVER seem to unload the DLL.
This caused us to have to stop and start Virgo completely when updating that bundle. Which happens every time we install a new "Base" package. This is a very time consuming process, since Virgo is taking up to 10 minutes before it's completely started, which is actually another problem, but we haven't even started to try to resolve that.
2) When stopping and starting Virgo, it didn't always load bundles in the same order, which meant that sometimes it wouldn't load the provider bundles before the dependent bundles (Which is how this message stays on topic)
3) Virgo startup times takes a long time before all the bundles are loaded and started..
We probably need to revisit the way that things were ported. Because it seems that the Virgo bundle loader isn't very intelligent about the Bundle Dependency resolution. Making sure to load and start provider bundles before the dependent bundles are started. Given the stated goal of OSGI to allow for bundles to be replaced easily, I believe that we were naive in the way that we expected things to work. But what use is the Bundle Dependency information in the Manifest if the loader doesn't use it to provide some sort of load order hints.
I am looking for more information on the best way to resolve these problems. One solution for the JNI situation that has been proposed, is to switch to JNA instead. From earlier comments in this thread, it sounds like we should be going one step further, and extracting out an interface first, and deploy that into the user-repository directory, and then have our bundle provide that interface. The other bundles would then depend on the interface bundle, not the provider bundle. Does that mean we need to do something special in the dependent bundle initialization routines? What happens when the provider bundle gets stopped or replaced? What happens when we want to add functionality to the interface? How are you supposed to replace bundles stored in the user repository?
|
|
|
| Re: Order of bundle installation [message #1270572 is a reply to message #1270166] |
Thu, 13 March 2014 02:50 |
| Eclipse User |
|
|
|
Wow, that's quite a post. I'll try to answer a few points from my experience, although the core devs might have more insight.
So, the OSGi-way of updating your interface bundles would be to update (increase) their version number and deploy them to the repository. Manifest dependencies are used just for that - they don't have anything to do with OSGi services, they just tell what packages and what version of class definitions a bundle needs to run. Of course, when you update the interface bundle version, you also need to update the imports for all the bundles that use them (or use version ranges in imports so that minor updates to interface bundles are already accounted for).
A consequence of the above is that you'd want to re-wire your bundles to the new version of interface bundle. A core dev might have the best suggestion on how to do that, I'm not sure but maybe it can be done through JMX or from a gogo shell so you can shell-script it.
As for long Virgo startup times - I don't know how your bundle services are wired, but in your case they seem to work as if you're using spring-dm "single service" references. Those kind of references do indeed block the loading until a service reference is satisfied (i.e. they're "Waiting for service to become available"). However, there is also a "set reference" you can use where the bundle will start immediately, even though a service it references is not available. When it does become available, Virgo will wire the service into your bundle and you can use its reference from then on. This does require some additional checks in your code (testing to see if the service reference is not null), but it decouples your bundles completely and you can then independently remove and update any of them without the need to restart the whole server.
Hope that helps a bit...
|
|
|
Powered by
FUDForum. Page generated in 0.03784 seconds
Home