[jboss-dev-forums] [JBoss Microcontainer Development] - Re: Potential deadlock in ClassLoaderManager

[adrian@jboss.org]

"wolfc" wrote : 	at org.jboss.classloader.spi.base.ClassLoaderManager.unregisterLoaderThread(ClassLoaderManager.java
  |   | :128)
  |   | 	- locked <0x95a17ae8> (a java.util.Collections$SynchronizedList)
  |   | 	- locked <0x95a17ae8> (a java.util.Collections$SynchronizedList)
  | taskList == toTaskList

Yes, that's what I said above about it looping.

We had that problem before
https://jira.jboss.org/jira/browse/JBCL-81
which I fixed by making the code more like the UCL stuff from 4.2.x

This maybe a different variation of the problem (one which would also make the
4.2.x code loop as well), but I can't tell.

I can't reproduce the problem (although Thomas says he can) and the TRACE
logging he posted on the JIRA issue doesn't match the thread dump.
There is no "Reassigning task:" logging at all in his log which we would expect
from stacktrace since it occurs just before the list.add()

There are some other incongruencies with the log as well
(e.g. the thread dump shows it using a BaseClassLoader as the parent
classloader for the Domain, but the log shows all the parents to be the JDK classloader).

Anyway, I've applied a fix that stops this add() looping if it tries to reassign
ThreadTasks to itself. This is in a snapshot here (number 14):
http://snapshots.jboss.org/maven2/org/jboss/cl/jboss-classloader/2.0.7-SNAPSHOT/
So we can see whether this fixes the problem Thomas is seeing.

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

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