Hi Am 17.12.2013 um 14:25 schrieb 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… I think there is a patch around somewhere in the issues where I proposed to actually implement such a loop and timeout in the acquireGlobalLock method itself. Yet, it does not solve the problem really so we never applied. >> >> 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). This sounds promising. Unfortunately we hit this deadlock every now and then, even though we try hard to setup our system to prevent (for example by carefully leveraging the start level service on startup; nasty but pragmatic) them. Regrds Felix > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
