One real problematic use of the global lock is when a bundle attemps to resolve a dynamic import package. This can lead to deadlocks because this can happen whenever a class is loaded, and that can't be controlled. This is a common use case when using asynchronous extenders, see https://issues.apache.org/jira/browse/FELIX-4308.
2013/12/17 Richard S. Hall <[email protected]> > On 12/17/13, 04:36 , Tang Yong wrote: > > Hi All, > > > > I met an issue as the following, > > > > ... > > Caused by: org.osgi.framework.BundleException: Unable to acquire global > > lock for resolve. > > at > org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3832) > > at org.apache.felix.framework.Felix.startBundle(Felix.java:1868) > > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944) > > ... > > > > Richard said the issue is not a bug[1] of felix, and I also agree with > him. > > > > However, I want to say once we truely met the issue and try to catch the > > exception on upper layer, how can we do? > > > > I think that best way should be: felix offered some api to let us > > retrieve whether bundle lock has been released by other thread. > > > > The second way can be: do a loop and wait for the changing of current > > bundle state, and set a timeout to avoid infinite loop. > > > > The third way should be: adjusting upper layer's bundles and decoupling > > them to avoid the case... > > > > Want to listen your ideas. > > The main way I'd like to address this issue is to simply avoid it by > eliminating the use of the global lock altogether. What I had thought > about long ago was to simply make resolving optimistic so that it would > work on a copy of the framework state and if the framework state changed > at the end of the resolve, it would try to resolve again until the > framework state didn't change (perhaps with a retry limit). > > The only other place that uses the global lock is for refreshing, but we > could probably eliminate it there in a somewhat similar fashion by > calculating all needed bundle locks in advance and locking all bundles > individually (you'd still need to double check the calculation to make > sure nothing changed and potentially release and try again). > > -> richard > > > > > [1]: > http://mail-archives.apache.org/mod_mbox/felix-users/201102.mbox/%[email protected]%3E > > > > Thanks > > Tang > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
