felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Humeniuk, David P" <David.Humen...@udri.udayton.edu>
Subject RE: Race conditions with bundle states
Date Sat, 23 Mar 2013 13:09:57 GMT
I guess to give some background, the listener service (that is listening for the bundle installed/updated
events) is there to send a message to another OSGi instance when new Metatype information
is available.  That is why we are listening for installed/updated bundles to know when to
parse them and send information about the Metatype information.

So the information would only really be available if the bundle can be resolved right?   At
least looking the metatype service the findEntries() method is how it finds the XML metatype
files.  So I suppose waiting for the RESOLVED event would make the most sense.

-----Original Message-----
From: Neil Bartlett [mailto:njbartlett@gmail.com] 
Sent: Friday, March 22, 2013 9:13 AM
To: users@felix.apache.org
Cc: Allen, Cheryl L
Subject: Re: Race conditions with bundle states

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:39
> > 80)
> >
> >     [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
View raw message