Thanks all's reply very much! Felix Meschberger 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. Surly, loop and timeout can not resolve truly issue. Often, these issues is caused by upper layer's bad design...
> >>> 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. Yes, I am applying some patch for my case by adjusting some modules's starting levels or virtually, these modules should have starting orders. Thanks Tang > > 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] > > > -- −−−−−−−−−−−−−−−−−−−−−− 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]
