Community
Participate
Working Groups
Build Identifier: I20100608-0911 Currently there does not seem to be a safe way to use BundleContext.registerService() in an Equinox DS environment, unless the call is executed in a context where a lock in org.eclipse.equinox.internal.ds.InstanceProcess is already acquired. This lock is held when a components activate/deactivate or bind/unbind methods are called, but of course not if registerService() is invoked from a separate thread. The problem is that registerService() will block on the mentioned lock if it is already held by another thread. However, if this thread for example calls a deactivate() which in turn wants to wait until the first thread has died, then the two threads will deadlock (until a timeout is triggered at least). Interrupting the thread that calls registerService() does not do anything since that exception is swallowed. The same problem exists with ServiceRegistration.unregister(). Possibly related bugs: #325409, #326309 Workarounds: None, except for changing the source code or using runtime introspection hackery to check the state of the InstanceProcess lock before calling registerService(). Reproducible: Always Steps to Reproduce: 1.Create a component that spawns a thread in activate() that waits a while and then call BundleContext.registerService(). In deactivate(), try to join said thread. 2.Activate the component and then deactivate it again. 3.If deactivate() was called just before registerService() was called, the threads will deadlock.
Created attachment 193690 [details] Stacktrace
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
It is shameful there was not a single comment on this bug besides from the originator. We have since upgraded to using Felix SCR implementation which has been more thoroughly tested with multithreaded scenarios. I am fairly confident such issues described in this bug work with the Felix SCR implementation.
Ha, I remember this bug! 2011, what a time to be alive. Surprisingly I even had this login information saved even if I don't have any control over the email anymore. Anyway, I have no idea if the bug is still there or not, but I can provide some closure if anyone out there wonder what we did about it. Essentially we determined that there were no way we would be able to fix the Equinox implementation so we switched to Felix instead. Unfortunately it turned out that Felix had just as many multi-threading bugs. While trying to figure out if we could fix _those_ bugs instead, we eventually concluded that the problem was in the OSGi interfaces themselves. There were simply no way the interfaces could be implemented that would be safe for our usecases. So I ended up writing a custom component manager over a weekend and then we removed all traces of OSGi from our application. Worked like a charm! I wish we had open sourced it. Please remember that this was yeeears ago. None of these issues might be applicable today. It's always fun to tell the story about it though.
