On 12/18/13, 09:06 , Daniel McGreal wrote: > 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.
I don't think they are related. Your issue deals with class loader locks, not the global lock (which is a Felix framework-specific thing). -> richard > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
