This looks like an inconsistent locking strategy. ServiceRecipe.getService() is synchronized on the ServiceRecipe instance and then obtains the blueprintRepository instance lock in ServiceRecipe.internalGetService. However, in the JIRA the Blueprint-Extender 1thread is already holding the blueprintRepository instance lock due to starting up and creating the blueprints.
At the very least the locks should always in the opposite order with the blueprintRepository instance lock being obtained first (because a thread might already be holding it) and then getting the smaller ServiceRecipe instance lock. But I'd say the real issue is that the thread that creates blueprints (and holds the blueprintRepository instanceLock) invokes all kinds of listeners while holding the lock leading to this issue ... Regards, Valentin On 26 Aug 2010, at 13:34, Rick McGuire wrote: > Kevan Miller just opened a Geronimo Jira for what appears to be a blueprint > synchronization issue. See > > https://issues.apache.org/jira/browse/GERONIMO-5554 > > It appears there's a three-thread lock cycle going on here caused by a race > condition between starting bundles that are making service requests. > > He's only seen this once, but this could be a fairly serious issue for > Geronimo. If possible, it probably should be addressed in the 0.2 release. > > Rick
