[jboss-jira] [JBoss JIRA] Reopened: (JBAOP-501) Deadlock involving exclusively AspectManager and ClassLoader locks

Deadlock involving exclusively AspectManager and ClassLoader locks ------------------------------------------------------------------ Key: JBAOP-501 URL: http://jira.jboss.com/jira/browse/JBAOP-501 Project: JBoss AOP Issue Type: Sub-task Security Level: Public(Everyone can see) Affects Versions: 2.0.0.CR2 Reporter: Flavia Rainone Assigned To: Flavia Rainone Fix For: 2.0.0.GA Attachments: aop_deadlock.txt This deadlock involves only the AspectManager and the class loader locks. The scenario, result of a rebuildingchain test execution, follows: -Thread 0 (org.jboss.test.aop.rebuldingchain.SyncThread) When this thread calls the joinpoint SyncThread.checkStatus, its wrapper is executed. This wrapper needs to generate the Joinpoint class to perform the interception and, for that, it has to acquire the read lock for InterceptorChain. This thread starts waiting for Thread1 to release the interceptor chain write lock. - Thread 1 (org.jboss.test.aop.rebuildingchain.RebuildThread) This thread adds a binding to AspectManager. As part of the addBinding method execution, the AspectManager lock is acquired. As soon as the binding is addded to the bindings collection, the affected advisors have to rebuild their interceptor chains. SyncThread advisor is the affected advisor in this scenario and, to rebuild chains, it needs the write lock for the SyncThread.checkStatus inteceptor chain. This lock is acquired and the rebuild chain algorithm starts being executed. During the finalization of fhe chains, interceptors are created. For that, the interceptor class needs to be loaded, so this thread starts waiting for the class loader lock, held by Main Thread. - Main Thread Test tries to finish execution (without joining the other threads) and, for that, it starts loading a class, acquiring the class loader lock. The class loading proccess triggers AOPTransformer, that tries to transform the loaded class. For that, the AspectManager lock, held by Thread1, is required, so thist thread starts waiting for that lock. Notice that the deadlock involves only Thread1 and MainThread (Thread0 is present only for completion).