On 2/2/11 10:47, Arjun Panday wrote:
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.
This is not necessarily a bug. That can happen if your bundle is holding
a bundle lock and you try to acquire the global lock, which in this case
the thread holds the bundle lock for the bundle it is trying to start
and it needs the global lock to resolve it. If someone else already has
the global lock and needs a bundle lock, then it will interrupt the
other thread only holding the bundle lock. This avoids deadlocks.
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.
Originally, we weren't using Java 1.4 methods, but we do now.
-> richard
regards,
Arjun
On 10/12/2010 08:30 PM, [email protected] 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"<[email protected]>
To: [email protected]
Sent: Tuesday, October 12, 2010 2:14:13 PM
Subject: Re: Unable to acquire global lock for resolve
On 10/12/10 13:56, [email protected] 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"<[email protected]>
To: [email protected]
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, [email protected] 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: [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]
---------------------------------------------------------------------
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]
