"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-SN... 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#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...