Adam,
Thank you for the update. I am pleased the information I forwarded was
helpful even if I was barking up the wrong tree :)
I believe the JIRA issue system is becoming increasingly important to
developers. Given the nature of this problem I feel it would be
presumptuous of me to categorize it properly - it might be best if you
do so.
I would like to note some tools I discovered while following up on
Marshall's suggestions (an earlier email.) I am using Java6, in a
Windows XpPro environment, and it comes with two useful tools. Quoting
one of the links I found "Those tools are jps (a ps for Java processes)
and jstack (a tool to dump the threads of a specified Java process)".
With these tools I was able to "discover" and then "see" from the
command line into an Eclipse Debug session. They may be of use to others.
Thank you again Adam,
Bill
Adam Lally wrote:
<snip/>
Bill,
I think I see where the problem is, thanks to your stack trace:
<snip/>
I took a look at the code for
AnalysisEnginePool.setResultSpecification. It tries to set the result
specification of all AEs in the pool. To do this it attempts to check
out all instances from the pool, set their result spec, and then
releases them all. If this method is executed simultaneously from two
threads, it can easily result in deadlock (each thread has some
portion of the instances checked out and is trying to check out the
remainder of them, and both will wait forever).
And this method is called from the process(CAS, ResultSpecification)
method, called in this test case from multiple threads.
This design is broken and I'll need some time to figure out what to
do. In the mean time feel free to open a JIRA issue.
Thanks for helping debug this,
-Adam
