You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Guillaume Nodet (JIRA)" <ji...@apache.org> on 2012/12/06 09:33:03 UTC

[jira] [Created] (FELIX-3806) Some bundle events are sent to SynchronousBundleListeners without holding the bundle lock which can cause the event to be delivered out of order

Guillaume Nodet created FELIX-3806:
--------------------------------------

             Summary: Some bundle events are sent to SynchronousBundleListeners without holding the bundle lock which can cause the event to be delivered out of order
                 Key: FELIX-3806
                 URL: https://issues.apache.org/jira/browse/FELIX-3806
             Project: Felix
          Issue Type: Bug
          Components: Framework
            Reporter: Guillaume Nodet


This can be very troublesome for extenders which react to the STARTED / STOPPING events for example.
If two threads are starting / stopping the bundles, those two events can be delivered out of order.
The spec mentions that pathological listeners can lead to such results, but that's only because the listener does change the state by calling back the framework.

The above out of order delivery is very difficult to overcome when writing extenders because the bundle can be stopped concurrently while processing the STARTED event.

I've seen the purpose of this behavior is to enable bundles to modify the lifecycle of the bundles in reaction to the STARTED event.
However, I don't understand this objection.  If the thread holding the lock calls back into the framework to stop the bundle, the lock is reentrant and that should work.
If the work is done in a separate thread, the thread will wait until the STARTED event is processed and that should not be a problem.

So I suggest moving back the STARTED and STOPPED events inside the bundle lock.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira