Community
Participate
Working Groups
Build Identifier: 2.1.1.RELEASE When uploading a bundle with "Bundle-ActivationPolicy: lazy" set in the MANIFEST.MF the admin will hang. The bundle will show as "RESOLVED" and the logs will say "<DE0004I> Starting bundle 'bundle name' version 1.0.0". Only uninstalling the bundle will allow the admin to process newly uploaded bundles. Reproducible: Always Steps to Reproduce: 1. Add "Bundle-ActivationPolicy: lazy" to a MANIFEST.MF 2. Upload the bundle via the Virgo admin
Thanks for raising this. I note the importance is "minor" but it would be good to fix this bug. I haven't tried it, but presumably the admin console continues to be usable after refreshing the browser?
Created attachment 196431 [details] Lazy bundle to recreate issue I have recreated this bug on a recent 3.0.0.x build but adding 'Bundle-ActivationPolicy: lazy' to the manifest of the splash screen app. Steps to reproduce, 1. Replace the splash screen app with the one attached to this issue. 2. Start the server up 3. Go to the Admin app and the app is correctly 'RESOLVED' trying to start it just hangs Note, the admin console can still be used and the bundle can be started from the OSGi console so for some reason using the mBeans isn't working when it's a Lazy bundle.
Looking at the code I'm not so sure these are related as the uploader doesn't go through the mBeans to do the deployment.
Thanks for taking a look at it. I marked it minor because: 1) It breaks functionality, but there are workarounds 2) It affects major functionality through a minor irritation in a limited set of cases 3) It does not cause crashing of the server or the client 4) It does not cause performance degredation 5) It does not cause data loss I did notice that I cannot upload a "lazy" bundle and follow it with another bundle (the system will hang) until I remove the lazy bundle from the system. Aside from that, the console is still usable.
I noticed that after the lazy start bundle has been uploaded, the OSGi bundle is in the STARTING state but the admin console shows the bundle install artifact as being in the RESOLVED state.
5 minutes after the upload the following messages is displayed in the event log and console: <DE0502E> Start of bundle 'org.eclipse.virgo.apps.splash' version '3.0.0.D-20110523150747' has taken longer than the configured timeout of '{}' seconds. (Note that insert is incorrect.)
The problem is due to the default, non-standard behaviour of Equinox. Lazy activation has been part of Eclipse long before it was part of the specification. Prior to spec'ing lazy start at OSGi, Eclipse would automatically place a lazy start bundle into the "waiting for trigger class load mode" even if Bundle.start(useActivationPolicy) was not called. In order to continue supporting this mode Equinox has a compatibility configuration flag (osgi.compatibility.eagerStart.LazyActivation) which defaults to true. Basically this means the framework will automatically call Bundle.start(START_ACTIVATION_POLICY) for all resolved bundles that have a lazy activation policy. This automatically places them into the STARTING state and waiting for a trigger class load. This behaviour conflicts with the way bundles are deployed by Virgo. Virgo calls Bundle.start() which is equivalent to Bundle.start(0) which will ignore the activation policy and cause the bundle to be eagerly (and persistently) started. The fix is to set Equinox to conform to the OSGi specification in this respect by setting: osgi.compatibility.eagerStart.LazyActivation=false in lib/org.eclipse.virgo.kernel.launch.properties.
Fixed the Equinox setting in kernel commit 2ff56518564a51e5f05c18acf555c2c51ad40f7d.
