"bstansberry(a)jboss.com" wrote :
| Specifically, it's inside the "while (taskList.isEmpty() == false)"
block, which leads me to question whether somehow the taskList is never empty. (Uneducated
guess: somehow taskList == toTaskList, so this becomes a loop adding and removing
threadTask???)
|
I'm also not totally sure how this code works either. :-)
It is a copy of LoadMgr3 from the UnifiedClassLoader which I tried to simplify
but couldn't get it work so I left it as it was. ;-)
But I don't believe taskList == toTaskList should ever be true.
The purpose of this loop is to reassign classloading tasks to other threads because
this thread has finished doing its classloading. It shouldn't be the
"requestingThread"
on those classloading tasks. If it were, the nextTask() should have already done them.
Simplifying your second set of stack traces:
| Trace1:
| "Incoming-2,192.168.1.5:42274" prio=10 tid=0x0000000040353800 nid=0x2b3a
runnable [0x000000003a2fc000..0x000000003a2ffb70]
| java.lang.Thread.State: RUNNABLE
| at java.lang.Object.notify(Native Method)
| at
org.jboss.classloader.spi.base.ClassLoaderManager.unregisterLoaderThread(ClassLoaderManag
| er.java:127)
| - locked <0x000000001ce12608> (a
java.util.Collections$SynchronizedList)
| - locked <0x000000001ce12608> (a
java.util.Collections$SynchronizedList)
| at
org.jboss.classloader.spi.base.BaseClassLoader.unlock(BaseClassLoader.java:1011)
| - locked <0x00000000199bace8> (a
org.jboss.classloader.spi.base.BaseClassLoader)
| at
org.jboss.classloader.spi.base.BaseClassLoader.unlock(BaseClassLoader.java:894)
| at
org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:289)
|
| Trace 2:
| "ajp-192.168.1.5-8009-2" daemon prio=10 tid=0x000000004575b800 nid=0x2b76 in
Object.wait() [0x00000000028b6000..0x0000000002
| 8b9c70]
| java.lang.Thread.State: WAITING (on object monitor)
| at java.lang.Object.wait(Native Method)
| - waiting on <0x000000001dbed570> (a
java.util.Collections$SynchronizedList)
| at java.lang.Object.wait(Object.java:485)
| at
org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:207)
| - locked <0x000000001dbed570> (a
java.util.Collections$SynchronizedList)
| at
org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:148)
|
| Trace 3:
| "Incoming-2,192.168.1.5:42274" prio=10 tid=0x0000000040353800 nid=0x2b3a
runnable [0x000000003a2fc000..0x000000003a2ffb70]
| java.lang.Thread.State: RUNNABLE
| at java.lang.Object.notify(Native Method)
| at
org.jboss.classloader.spi.base.ClassLoaderManager.unregisterLoaderThread(ClassLoaderManag
| er.java:127)
| - locked <0x000000001ce12608> (a
java.util.Collections$SynchronizedList)
| - locked <0x000000001ce12608> (a
java.util.Collections$SynchronizedList)
| at
org.jboss.classloader.spi.base.BaseClassLoader.unlock(BaseClassLoader.java:1011)
| - locked <0x00000000199bace8> (a
org.jboss.classloader.spi.base.BaseClassLoader)
| at
org.jboss.classloader.spi.base.BaseClassLoader.unlock(BaseClassLoader.java:894)
| at
org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:289)
|
It's hard to tell without TRACE logging being enabled, but if Trace3 is really
showing
that thread still looping from Trace1 then it looks your "uneducated guess" is
correct.
i.e. Trace2 is showing a thread for the same classloader waiting on its thread task list
(0x000000001dbed570) while Trace1 and Trace3 is showing two locks on
(0x000000001ce12608).
| synchronized (taskList)
| {
| while (taskList.isEmpty() == false) // FIRST LOCK
| {
| ThreadTask threadTask = taskList.remove(0);
| ClassLoadingTask loadTask = threadTask.getLoadTask();
| Thread requestingThread = loadTask.getRequestingThread();
| if( trace )
| log.trace("Reassigning task: " + threadTask+" to
" + requestingThread);
| threadTask.setThread(null);
| // Insert the task into the front of requestingThread task list
| List<ThreadTask> toTaskList =
loadTasksByThread.get(requestingThread);
| synchronized (toTaskList) // SECOND LOCK
| {
| toTaskList.add(0, threadTask);
| loadTask.nextEvent();
| toTaskList.notify();
| }
| }
| }
|
So the issue is to try to figure out how that could happen.
If you know how to reproduce the problem, enabling TRACE logging
for org.jboss.classloader would help greatly. ;-)
I don't think your second guess is correct? The one about the remove
being outside the synchronized block. The code is the same as JBoss4.x
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206557#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...