Mailing-List: contact users-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@felix.apache.org
Received-SPF: pass (nike.apache.org: domain of fmeschbe@adobe.com designates
 64.18.1.25 as permitted sender)
From: Felix Meschberger <fmeschbe@adobe.com>
To: "users@felix.apache.org" <users@felix.apache.org>
CC: "Allen, Cheryl L" <Cheryl.Allen@udri.udayton.edu>
Date: Fri, 22 Mar 2013 12:58:47 +0000
Subject: Re: Race conditions with bundle states
Thread-Topic: Race conditions with bundle states
Thread-Index: Ac4m/P16hABbHwU/RtGJj219aVyudw==
Message-ID: <FA733F1E-950B-45B2-A3BB-5B727D92E5E0@adobe.com>
References: 
 <A975FF8AB08DF34A8F8B33B49EE079F2044217C8@ri-exch.udri.udayton.edu>
In-Reply-To: 
 <A975FF8AB08DF34A8F8B33B49EE079F2044217C8@ri-exch.udri.udayton.edu>
Accept-Language: de-DE, en-US
Content-Language: en-US
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi

I have the impression, that from your event handler you should not cause th=
e bundle to be resolved.

Wouldn't you want to wait for the RESOLVED event ? Or event the STARTED eve=
nt ?

Regards
Felix

Am 22.03.2013 um 13:43 schrieb Humeniuk, David P:

> I have a thread that does a Bundle.update() call.
>=20
>=20
>=20
> I have an EventAdmin based EventHandler that listens for bundle updated
> events.  The event handler will call Bundle.findEntries which causes a
> resolve of the updated bundle.
>=20
>=20
>=20
> The update call will sometimes fail with the exception:
>=20
>=20
>=20
>     [java] ERROR   20130321 23:34:11 ID#19 - Request to update bundle 9
> failed.
>=20
>     [java] org.osgi.framework.BundleException: Unable to acquire global
> lock for resolve.
>=20
>     [java] Caused by: org.apache.felix.log.LogException:
> org.osgi.framework.BundleException: Unable to acquire global lock for
> resolve.
>=20
>     [java]     at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3980)
>=20
>     [java]     at
> org.apache.felix.framework.Felix.startBundle(Felix.java:2037)
>=20
>     [java]     at
> org.apache.felix.framework.Felix.updateBundle(Felix.java:2404)
>=20
>     [java]     at
> org.apache.felix.framework.BundleImpl.update(BundleImpl.java:973)
>=20
>=20
>=20
> We are running the latest Framework 4.2.1.  We also seen this happen
> previously on 4.0.3.
>=20
>=20
>=20
> So the event handler will be triggered to resolve bundles and acquires
> the global lock, then later the thread doing the update will try to
> resolve and get the global lock (but the other thread wants its bundle
> lock).  So I guess the code does what it needs to, to prevent a deadlock
> state.  I guess I'm wondering, how should I be trying to interact with
> the API in this case.  Should I be putting a retry on my update call?
> Something else?  Is there something that explains the different locks
> and how to work with them in the API or elsewhere?
>=20
>=20
>=20
> Thanks,
>=20
> Dave Humeniuk
>=20
> Software Engineer
>=20
> Sensor System Division (SSD)
>=20
> University of Dayton Research Institute
>=20
>=20
>=20


--
Felix Meschberger | Principal Scientist | Adobe


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