I'm not sure why you cannot just activate every bundle at launch if you don't care about lazy activation. Is that what you tried to do but it failed?
A testcase would really help here. You mention lots of locks below but I'm not sure if these are class loader locks established by the vm or framework locks associated with Bundle lifecycles or DS impl locks. I suggest you open a bug against Equinox->Framework to track dead lock issues you are seeing with lazy activation. If class loading locks are causing the issue then I suspect you are running into a flavor of https://bugs.eclipse.org/bugs/show_bug.cgi?id=121737. Locking the class loader at the VM level is blocked by a long standing Sun http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4670071. It would be interesting to know if the VM args mentioned at https://bugs.eclipse.org/bugs/show_bug.cgi?id=121737#c8 help solve your problem. Tom From: "Jan Stette" <[EMAIL PROTECTED]> To: "Equinox development mailing list" <equinox-dev@eclipse.org> Date: 05/21/2008 08:09 AM Subject: Re: [equinox-dev] Equinox lazy bundle start and deadlocks I'm running with a fairly recent version of the ProSyst DS. I don't think this deadlock is the same as the ones in the bugs you mention though (we saw those earlier before we got patches for those). Specifically, those bugs don't involve lazy bundle starting. It seems to me that there's an inherent problem with the lazy bundle starting. What we're seeing is that one thread goes through the steps: Bundle is activated -> DS is notified, gets lock -> enters class loader as part of activating a service, gets lock. Whereas a second thread does: Enters class loader, gets lock -> bundle is lazily loaded -> DS is notified, gets lock. So in one thread, a lock in DS is held before the classloader lock is acquired, in the other thread the classloader lock is held then it calls out to DS which will acquire a lock. Maybe it would be possible to work around this specific case by juggling locks inside the DS implementation. But it just seems to me that it would be very difficult to guard against future errors along this line. Basically, the lazy bundle loading means that any innocent-looking line of code like: Widget = new Widget(); anywhere in my code can cause a very long chain of synchronous events including calling back out to my code through bundle and service listener interfaces. Ensuring that locking is correct in all situations seems completely impossible, so I'd much rather just turn lazy loading off. Any suggestions for what is the best way to do this? Regards, Jan 2008/5/21 Thomas Watson <[EMAIL PROTECTED]>: The deadlock you describe sounds similar to the issues we were dealing with in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=199103 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=186280. Both of these bugs have been addressed in 3.4. What version of Declarative Services are you using? Is it the latest graduated implementation from Equinox? Can you try 3.4? To answer your second question we need more information on the set of eclipse bundles you need for your application. Tom Inactive hide details for "Jan Stette" ---05/21/2008 07:19:46 AM---I'm seeing some deadlock problems with Equinox lazy bundle s"Jan Stette" ---05/21/2008 07:19:46 AM---I'm seeing some deadlock problems with Equinox lazy bundle starting, much as described at From: "Jan Stette" <[EMAIL PROTECTED]> To: "Equinox development mailing list" < equinox-dev@eclipse.org> Date: 05/21/2008 07:19 AM Subject: [equinox-dev] Equinox lazy bundle start and deadlocks I'm seeing some deadlock problems with Equinox lazy bundle starting, much as described at http://wiki.eclipse.org/Lazy_Start_Bundles. This page suggests that these were only occurring in 3.2, but I'm running with Equinox 3.3. What is the status of resolving these issues? I should mention as well that I'm using Declarative Services, and that this is involved in the deadlocks I've seen so far. The problems relate to the declarative services code being registered as a bundle listener hence getting callbacks when bundles are lazily started. It then synchronously proceeds to read component specifications and activating services (hence calling out into client code). Having all this happening synchronously on a callback essentially sourced from within a classloader seems like a recipe for problems! I'm working on a server-side application so I actually don't care about lazy start at all. So to work around the problem, I tried disabling the EclipseLazyStarter hook using the osgi.hook.configurators.exclude system property. This caused problems when starting some Equinox bundles that would look for services that hadn't been registered. Presumably because the bundles providing these services depend on being started via the lazy start mechanism. I then tried working around this by ensuring I listed all necessary bundles in my config.ini with the right start level, but I found it difficult to come up with a working configuration here. Does anyone have any other suggestions for how I can run Equinox with lazy start disabled? Regards, Jan _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
<<inline: 27923237.gif>>
<<inline: 27214501.gif>>
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
