Hi William -
This behavior could be due to a deadlock, or it could be due to
something as simple as sending a request to a process and waiting for
the response, but the process died for some reason.
For deadlocks, many Java implementations have tools that can help
diagnose this by printing out what locks are being held. For instance,
the IBM Java 1.4.x has info about creating a "Javadump" which includes
information about locks; see
http://publib.boulder.ibm.com/infocenter/javasdk/v1r4m2/topic/com.ibm.java.doc.diagnostics.142/html/interpretjavadump.html#interpretjavadump
and in general, look here:
http://www-1.ibm.com/support/docview.wss?rs=3182&uid=swg27007948
If you're using Java 6 from Sun, this page may be helpful:
http://java.sun.com/developer/technicalArticles/J2SE/monitoring/
Look at the tools for diagnosis of common problems - Deadlocks
-Marshall Schor
William Surowiec wrote:
Adam,
I've spent some time with the code in the eclipse debugger and can
consistently cause a condition where all the threads are running but
no work happens. When you then suspend one of the application threads
it consistently stops at line 166 in
org.apache.uima.internal.util.ResourcePool (the statement
"wait(aTimeout);" I have extracted the method and list it below.)
This is the call stack when I suspend one of the running, but not
advancing the execution, threads:
Thread [Thread-1] (Suspended) Object.wait(long) line: not
available [native method] ResourcePool.getResource(long) line:
166
AnalysisEnginePool.setResultSpecification(ResultSpecification) line:
155
MultiprocessingAnalysisEngine_impl.setResultSpecification(ResultSpecification)
line: 122
MultiprocessingAnalysisEngine_impl(AnalysisEngineImplBase).process(CAS,
ResultSpecification) line: 200
MultiprocessingAnalysisEngine_implTest$ProcessThread.run() line: 363
The extracted method in ResourcePool:
public synchronized Resource getResource(long aTimeout) {
long startTime = new Date().getTime();
Resource resource;
while ((resource = getResource()) == null) {
try {
wait(aTimeout);
} catch (InterruptedException e) {
}
if (aTimeout > 0 && (new Date().getTime() - startTime) >=
aTimeout) {
// Timeout has expired
return null;
}
}
return resource;
}
I will continue puzzling over this problem but admit to re-opening
several of Doug Lea's books to renew my (never really put to use)
acquaintance with the concepts,
Bill
Adam Lally wrote:
<snip/>
The second problem is eventually one test seems to go to sleep and
never wakes up - ergo I cannot complete the build.
<snip/>
That's certainly a problem. There may be some race condition (that
particular testcase is multithreaded) that you see but we don't due to
different hardware characteristics or whatnot.
<snip/>
Any other debug support you could provide would be great, for example
if you can find out what line of the test is hung at.
-Adam
