[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Deadlock in DelegateUnitTestCase

[adrian@jboss.org]

If you can reproduce it can you try to debug it or
add enableTrace("org.jboss.classloader") to the  test.

There's obviously a bug somewhere since thread "B" is trying to unlock
the classloader:


  | "B" prio=1 tid=0x0000002ae35e1fa0 nid=0x536c waiting for monitor entry [0x0000000041563000..0x000000004
  | 1565c30]
  |         at org.jboss.classloader.spi.base.BaseClassLoader.unlock(BaseClassLoader.java:701)
  |         - waiting to lock <0x0000002acaf81e50> (a org.jboss.classloader.spi.base.BaseClassLoader)
  |         at org.jboss.classloader.spi.base.BaseClassLoader.unlock(BaseClassLoader.java:583)
  |         at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:286)
  | 

But at this point in the code "A" has it:

  |         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:4
  | 83)
  |         at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:158)
  |         - locked <0x0000002acaf81e50> (a org.jboss.classloader.spi.base.BaseClassLoader)
  | 

So the two questions are:
1) Is this is spurious unlock and "B" didn't have the lock?
2) Did "A" obtain the lock when it shouldn't have done?

I'd guess it is (1) since I didn't understand *fully* understand the
"release in next task" in the old LoadMgr3, I just copied the logic. :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081266#4081266

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081266