5 Replies Latest reply on Jan 14, 2008 9:15 AM by flavia.rainone

Deadlock scenarios

flavia.rainone Jan 2, 2008 2:02 PM

During rebuildingchain test execution, we are seeing a couple of deadlock scenarios... those are related to classload time weaving and dynamic AOP operations.

I have created a bug issue:
http://jira.jboss.com/jira/browse/JBAOP-499

With two subtasks:
http://jira.jboss.com/jira/browse/JBAOP-500
http://jira.jboss.com/jira/browse/JBAOP-501

The first scenario (JBAOP-500) started happening after bug fix JBAOP-480.
It can be stopped if JBoss AOP starts avoiding to transform the generated joinpoint classes (on class AOPTransformer). For that, simply adding an aop suffix to the generated class name would work.

However, in the second scenario, JBAOP-501, the deadlock can happen when one of the threads executes an AspectManager synchronized operation that needs to load an advisable class, while the other thread starts loading an advisable class. So, the first thread has AspectManager lock but needs the class loader lock, while the second thread has the class loader lock but needs the AspectManager one to try to transform the advisable class.

I have a suggestion to fix this, but I'm not sure it can be applied on the possible scenarios (this info is something we would need to gather).
My idea will work only if we can state that all the advisable instances that JBoss AOP creates during AspectManager synchronized method executions won't be instrumented. If this is true, we can start considering those instances as non-advisable instead of advisable. In this case, we would need to check if the class is advisable at method AspectManager.transform (which is non-synchronized), before calling translate (which is synchronized). This would halt the transformation process on the given deadlock scenarios before acquiring AspectManager lock, avoiding the deadlock.

Using the thread dump scenario provided by Stale as an example (described on task JBAOP-501), the deadlock happens when JBoss AOP loads an Interceptor class to create. In this case can we say that Interceptors shouldn't be instrumented? If we can, we can go for the approach above for this scenario.

1. Re: Deadlock scenarios

flavia.rainone Jan 2, 2008 2:04 PM (in response to flavia.rainone)

In the given example, deciding that interceptors shouldn't be instrumented would be the same as creating a new restriction. However, how many people intercepts an interceptor? Probably not a very common use case, nor a good practice to be followed, IMHO.
Actions
2. Re: Deadlock scenarios

kabirkhan Jan 7, 2008 7:24 AM (in response to flavia.rainone)

"flavia.rainone@jboss.com" wrote:
In the given example, deciding that interceptors shouldn't be instrumented would be the same as creating a new restriction. However, how many people intercepts an interceptor? Probably not a very common use case, nor a good practice to be followed, IMHO.

I had this discussion with Bill ages ago, and IIRC the outcome was that it should be possible to intercept an interceptor. I don't remember the use cases though!

BTW there is an interface called org.jboss.aop.instrument.Untransformable that can be implemented to "turn off" weaving for a class
Actions
3. Re: Deadlock scenarios

flavia.rainone Jan 7, 2008 7:44 AM (in response to flavia.rainone)

The check for Unstransformable is done inside the synchronized block.

So, we could move this check for transform method, for example, avoiding the deadlock to happen with untransformable classes. But what about the transformable interceptors?
Actions
4. Re: Deadlock scenarios

flavia.rainone Jan 14, 2008 8:57 AM (in response to flavia.rainone)

If we don't come up with a better idea, I suggest forcing the class loading of all "problematic" classes before any instrumentation takes place.

This way, we would load and try to transform interceptors, for example, before transforming any other class (maybe this could be done inside the instrumentor).
Actions
5. Re: Deadlock scenarios

flavia.rainone Jan 14, 2008 9:15 AM (in response to flavia.rainone)

...maybe this could be done inside the instrumentor).

I mean, inside the agent.
Actions

Go to original post