Deadlock in blueprint running under Geronimo.

[Rick McGuire <ri...@gmail.com>]

  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

Re: Deadlock in blueprint running under Geronimo.

[Valentin Mahrwald <vm...@googlemail.com>]

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