+1 agree with Richard. Tang
Richard S. Hall wrote: > 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] > > > -- −−−−−−−−−−−−−−−−−−−−−− Tang Yong Senior Engineer GlassFish Committer (OSGi & OSGi-JavaEE) OSGi Alliance Supporter Blog: http://osgizone.typepad.com/tangyong/ Nanjing Fujitsu NanDa Software Tec CO.,LTD http://www.fujitsu.com/cn/fnst Tel: +86-25-86630566-8310 Fax: +86-25-83317685 −−−−−−−−−−−−−−−−−−−−−− --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
