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:[email protected]] Sent: Friday, March 22, 2013 9:13 AM To: [email protected] 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 <[email protected]>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: [email protected] > For additional commands, e-mail: [email protected] > >
