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: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: [email protected] > For additional commands, e-mail: [email protected] > >
