felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Bartlett <njbartl...@gmail.com>
Subject Re: Race conditions with bundle states
Date Fri, 22 Mar 2013 13:13:24 GMT
Felix, bear in mind that this is the Event Admin delivery thread, which
must be a different thread from the update.

Intuitively I would say that calling a method that forces resolution should
block if resolution is already being processed in another thread. But I
don't have anything from the specification to back this up. It certainly
seems wiser just to wait for the resolve event (assuming that the bundle
was in RESOLVED prior to the update).

Neil

On Fri, Mar 22, 2013 at 12:58 PM, Felix Meschberger <fmeschbe@adobe.com>wrote:

> Hi
>
> I have the impression, that from your event handler you should not cause
> the bundle to be resolved.
>
> Wouldn't you want to wait for the RESOLVED event ? Or event the STARTED
> event ?
>
> Regards
> Felix
>
> Am 22.03.2013 um 13:43 schrieb Humeniuk, David P:
>
> > I have a thread that does a Bundle.update() call.
> >
> >
> >
> > 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.
> >
> >
> >
> > The update call will sometimes fail with the exception:
> >
> >
> >
> >     [java] ERROR   20130321 23:34:11 ID#19 - Request to update bundle 9
> > failed.
> >
> >     [java] org.osgi.framework.BundleException: Unable to acquire global
> > lock for resolve.
> >
> >     [java] Caused by: org.apache.felix.log.LogException:
> > org.osgi.framework.BundleException: Unable to acquire global lock for
> > resolve.
> >
> >     [java]     at
> > org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3980)
> >
> >     [java]     at
> > org.apache.felix.framework.Felix.startBundle(Felix.java:2037)
> >
> >     [java]     at
> > org.apache.felix.framework.Felix.updateBundle(Felix.java:2404)
> >
> >     [java]     at
> > org.apache.felix.framework.BundleImpl.update(BundleImpl.java:973)
> >
> >
> >
> > We are running the latest Framework 4.2.1.  We also seen this happen
> > previously on 4.0.3.
> >
> >
> >
> > 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?
> >
> >
> >
> > Thanks,
> >
> > Dave Humeniuk
> >
> > Software Engineer
> >
> > Sensor System Division (SSD)
> >
> > University of Dayton Research Institute
> >
> >
> >
>
>
> --
> Felix Meschberger | Principal Scientist | Adobe
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message