DM Server & lazy init

[zsee]

Hey folks,

probably there is an obvious explanation for this, but I just can't figure it out why it is happening...

Whenever I'm deploying a bundle having the header

Bundle-ActivationPolicy: lazy

or

Eclipse-LazyStart: true

DM Server still tries to launch it (even if noone tries to load any classes from it)...as in it moves into STARTING state and nicely stays there...
I would expect that such a bundle is not activated, until someone gets to using it.
It is even worse if such a bundle is deployed upon startup (eg. from STS), the server never finishes starting up, because that 'guilty' one seems to block the sequence, and times out eventually..

Can anyone explain me whether this is a bug or not, and if not, can this behaviour of DMS configured somewhere?

Cheers!

[Steve Powell]

Hi zsee,

From the OSGi Core Specification (4.1) I quote:

When a bundle is started using a lazy activation policy, the following steps must be taken:

• A Bundle Context is created for the bundle.
• The bundle state is moved to the STARTING state.
• The LAZY_ACTIVATION event is fired.
• The system waits for a class load from the bundle to occur.
• The normal STARTING event is fired.
• The bundle is activated.
• The bundle state is moved to ACTIVE.
• The STARTED event is fired.

This shows that moving to STARTING state is correct; it is the activation of the bundle (and the firing of the starting event) which is delayed until a class load.

If you are seeing the Bundle Activator being called early then there is a problem; o/w it may be working as designed.

Steve Powell

[zsee]

Hey Steve,

thanks for the answer. No, the activator is not called of course (but nothing else seems to happen either). I would not expect a server to "hang" waiting for a class load to occur...

For instance, I have a couple of lazy-activated bundles "packed" into a plan. This plan never finishes starting (and the next plan never begins installing its artifacts), because of the lazy-activated ones...

For me this implies that such bundles should be started last, and still if loading a class from any of those bundles are conditional, and if that does not happen, it will still time out eventually. (And I never get the dm Server get into started state.)

So yes, 'The system waits for a class load from the bundle to occur.' is accepted, but me thinks an OSGi container should carry on starting up.. (or, maybe I'm missing the point of the whole lazy activation concept).

Opinion, anyone?

Cheers!

[Steve Powell]

zsee,

Yes, of course the server 'hanging' is a problem. I did not expect it to hang in the way you describe. However, you implied in your first post that this only happened from STS.

I would expect a plan (with a lazily activated bundle reference) to not enter STARTED state, but I wouldn't expect that plan to block subsequent deploys. The time-out could cause a problem...

Can you boil this down to a simple testcase (without STS) and post the log here? Alternatively, raise a JIRA issue?

I know that in the past dm Server didn't support lazy activation; and that the full implications of trying to do so will interfere with the plan semantics (think atomicity, for example), so there are very many reasons for thinking that there are bugs here.

The underlying question which occurs to us here is: Why do you need lazy activation? We believe that this requirement arose from resource constraints on embedded systems, where the creation of a class loader (and context) was expensive. This ought not to be a problem with most server systems.

Related resource availability problems can always be dealt with in the activation class, and/or by using spring-loaded services. One possible future course of action might be to ignore lazy-activation policies altogether in an attempt to simplify the management of artefact deployment.

Steve Powell

[zsee]

hi again,

I'll try to test this out outside STS, when I find the time.

Actually I don't need lazy activation. The story is that I'm trying to fire up Eclipse Communication Framework, to be able to use remote services, which breaks down to deploying a couple of bundles/plugins from ECF, that do define lazy activation. I just tried to avoid manipulating the MANIFEST.MFs of these plugins, ie. use/deploy them as they are, but apparently I cannot.

Cheers!

[Steve Powell]

Hi zsee,
Thanks; that would be good.

Can you link the ECF bundles you are deploying here, so that if we get time, we can try out your scenario for ourselves?

Steve Powell

[added later: thanks for the plan file.]

[zsee]

Hi,

the ECF plugins (along with a couple of Equinox plugins) I deployed are listed in the attached zipped .plan file. (I downloaded the ECF 3.2 SDK and copied the plugins from there.)
I placed the plugins along with the .plan to the /repository/usr directory, and added the plan as an initial artifact to the com.springsource.kernel.userregion.properties file.

Of course I had to remove all Bundle-ActivationPolicy and Eclipse-LazyStart headers from these plugins, to get the plan started.

Cheers!

[AlexService]

We're seeing this too, with home-brewed bundles. It looks like if they declare lazy, then the startup mechanisms (e.g. taking from pickup/) blocks for 5m waiting while the lazy-start bundle is in the STARTING state, refusing to start any other bundles in the meantime.

Removing the lazy bundle activation policy solved the problem.

Are there any examples or test cases where dm server works nicely with bundles that declare lazy activation?

Thanks
Alex