felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arjun Panday <arjun.pan...@alcatel-lucent.com>
Subject Re: Unable to acquire global lock for resolve
Date Wed, 02 Feb 2011 15:47:54 GMT
Hi,

For the record, I've had the same error recently reported to me :
org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.apache.felix.shell.remote [60]: Unable to acquire global lock for 
resolve.
         at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3416)
         at org.apache.felix.framework.Felix.startBundle(Felix.java:1714)
         at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)

It happened on an installed platform using Felix 3.0.4.
Unfortunately they didn't provide me with a jstack dump and the problem 
was not reproduced after a restart of the VM, so I know this message 
isn't of much help as such.

I also know that some resolver issues have been corrected in later 
versions of Felix, but I'm not sure whether this is one of them.

Incidentally, I noticed Exceptions thrown from the resolver and Felix 
implems were still built using
new Exception(msg + rootCause.getMessage())
as opposed to
new Exception(msg).initCause(rootCause)

It would probably help to keep the stack of root causes.

regards,
Arjun




On 10/12/2010 08:30 PM, mvangeertruy@comcast.net wrote:
>
> I did try this using Karaf 2.0.0 which uses Felix 3, unfortunately, because of the proprietary
nature of the implementation, I am unable to provide the stack-trace.  I'll try to get something
reproducable without my company's code and send it to you.
>
>
>
> v/r,
>
>
>
> Mike Van
>
>
> ----- Original Message -----
> From: "Richard S. Hall"<heavy@ungoverned.org>
> To: users@felix.apache.org
> Sent: Tuesday, October 12, 2010 2:14:13 PM
> Subject: Re: Unable to acquire global lock for resolve
>
>    On 10/12/10 13:56, mvangeertruy@comcast.net wrote:
>> Nope, this still is happening but the feedback on how to keep it from happening has
been negligible.
> Hmm. I last responded to you with a request for a reproducible scenario
> and the suggestion of trying it on a newer framework version if you
> hadn't already, but I didn't hear anything from you on either topic. So,
> what's up? Can you get me a scenario and did you try with the latest
> version?
>
> ->  richard
>
>>
>> v/r,
>>
>>
>>
>> Mike Van
>> ----- Original Message -----
>> From: "Richard S. Hall"<heavy@ungoverned.org>
>> To: users@felix.apache.org
>> Sent: Sunday, October 10, 2010 7:49:27 PM
>> Subject: Re: Unable to acquire global lock for resolve
>>
>> Any follow up on this?
>>
>> ->    richard
>>
>>
>> On 9/29/10 3:28 PM, Richard S. Hall wrote:
>>> On 9/29/10 15:19, Richard S. Hall wrote:
>>>>    On 9/29/10 12:59, mvangeertruy@comcast.net wrote:
>>>>> All,
>>>>>
>>>>>
>>>>>
>>>>> When attempting to deploy dom4j as part of a Hibernate 3 feature, I
>>>>> get the following error:
>>>>>
>>>>>
>>>>>
>>>>> Error executing command: Could not start bundle
>>>>> mvn:org.dom4j/com.springsource.org.dom4j/1.6.1 in feature(s):
>>>>> Unresolved constraint in bundle com.springsource.org.dom4j [59].
>>>>> Unable to acquire global lock for resolve.
>>>>>
>>>>>
>>>>>
>>>>> When attempting to deploy the feature a second time it resolves.
>>>>> However, in another feature for jdbc, no matter how many times I
>>>>> attempt to deploy the feature, the global lock never resolves.  Can
>>>>> anyone give me feedback about why this is happening?
>>>> This is a recent change to try to deal with potential deadlocks.
>>>> Typically, this situation arises when people are trying to do
>>>> refreshes and resolves at the same time. It shouldn't occur if you
>>>> are just trying to resolve bundles.
>>>>
>>>> If you have a reproducible scenario, open up a JIRA issue and
>>>> describe the precise steps to reproduce and I can take a closer look.
>>> Of course, this depends on which version of the Felix framework you
>>> are using...we made some changes in this area in version 3.0.2, I
>>> believe, so if you aren't using at least that version you should try
>>> to upgrade and see what happens with it.
>>>
>>> ->    richard
>>>
>>>> ->    richard
>>>>
>>>>> v/r,
>>>>>
>>>>>
>>>>>
>>>>> Mike Van
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message