Hi, I wonder if this issue could be the cause, or related to problems when running on JamVM (e.g. GNU Classpath) described here: https://www.mail-archive.com/[email protected]/msg31518.html Best, Dan.
On 18 Dec 2013, at 13:57, Felix Meschberger <[email protected]> wrote: > 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]
