On 4/4/07, William Surowiec <[EMAIL PROTECTED]> wrote:
Marshall.
Thank you, as I am using it I will pursue the Java 6 link.
I fear I may not be seeing a deadlock but rather the absence (because it
has already happened) of a notification to proceed - and not because a
process has died, but rather it has completed and sent the notifyAll()
message but the intended receivers were not at the wait() stage. In
short, the receivers will now be waiting for a message that will not arrive.
I admit to not knowing enough about Java concurrency to say this with
any conviction that it is even plausible let alone likely. But I am
reading several books and the source code and trying to arrive at a
hypothesis.
Bill,
I think I see where the problem is, thanks to your stack trace:
----------
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
---------
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
