[
https://issues.apache.org/jira/browse/UIMA-6129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16939442#comment-16939442
]
Marshall Schor commented on UIMA-6129:
--------------------------------------
Here's an approach that may work for you.
You could change the code for T2 to include something that would react to the
interrupt.
(I haven't tested this, so it may be buggy)
FutureTask<String> future = new FutureTask<>( () -> { long t
= System.currentTimeMillis(); while (System.currentTimeMillis() - t
<= 1000L) {
Annotation annotation = new Annotation(jcas, 0, 2);
annotation.addToIndexes(jcas);
// be responsive to thread interruptions
// ASSUME they will only be caused by the "cancel(true)"
method of FutureTask
// So - minor issue: if something else interrupts this
thread, it will stop...
if (Thread.currentThread.isInterrupted()) {
return "exiting due to cancel";
}
} return "success";
});
And, there is now a race condition - you have to in T1, wait in a loop for the
Future to finish:
catch (TimeoutException e) {
future.cancel(true);
while(!future.isDone()) \{Thread.sleep(100);}
e.printStackTrace();
The general principle, in task T2, in various spots, insert a test for
isInterrupted, and if found, figure out how to terminate the thread. In this
simple case, you can return, but in other cases, you might need to do a
"throw", and insure that in the call stack for the thread, there are no
"catchers" for the particular exception you're throwing.
> The thread may deadlock if other thread interrupted which use jcas
> -------------------------------------------------------------------
>
> Key: UIMA-6129
> URL: https://issues.apache.org/jira/browse/UIMA-6129
> Project: UIMA
> Issue Type: Bug
> Components: UIMA
> Affects Versions: 2.10.4SDK
> Reporter: li Gongrong
> Priority: Major
>
> I use FutureTask to kill the thread spend a lot of time，but it will cause
> deadlock.
> {code:java}
> at sun.misc.Unsafe.park(Native Method)at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000000070435e808> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> org.apache.uima.jcas.impl.JCasHashMapSubMap.getReserve(JCasHashMapSubMap.java:303)
> at org.apache.uima.jcas.impl.JCasHashMap.getReserve(JCasHashMap.java:318) at
> org.apache.uima.jcas.impl.JCasImpl.getJfsFromCaddr(JCasImpl.java:1154) at
> org.apache.uima.jcas.impl.JCasImpl$JCasFsGenerator.createFS(JCasImpl.java:912)
> at
> org.apache.uima.jcas.impl.JCasImpl$JCasFsGenerator.createFS(JCasImpl.java:873)
> at org.apache.uima.cas.impl.CASImpl.ll_getFSForRef(CASImpl.java:3751) at
> org.apache.uima.cas.impl.CASImpl.createFS(CASImpl.java:2231) at
> org.apache.uima.cas.impl.FSIteratorWrapper.get(FSIteratorWrapper.java:63) at
> org.apache.uima.cas.impl.FSIteratorAggregate.get(FSIteratorAggregate.java:76)
> at
> org.apache.uima.cas.impl.FSIteratorImplBase.next(FSIteratorImplBase.java:66)
> at
> org.apache.uima.cas.impl.FSIteratorImplBase.next(FSIteratorImplBase.java:32)
> {code}
> why ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
