Daemon thread prevents CPE exit
-------------------------------
Key: UIMA-1906
URL: https://issues.apache.org/jira/browse/UIMA-1906
Project: UIMA
Issue Type: Bug
Components: Collection Processing
Affects Versions: 2.3
Reporter: Timo Boehme
If a daemon thread was started within an AE and keeps running independent of
the AE processing (e.g. bound to a static variable) it prevents exiting of the
CPE.
Simple test:
add following class to a AE:
static class DaemonThread implements Runnable {
private static volatile Thread threadInstance;
/** Creates a daemon thread if it not already exists. */
public synchronized static void startThread() {
if ( threadInstance == null ) {
threadInstance = new Thread( new DaemonThread(),
"TestDaemon" );
threadInstance.setDaemon( true );
threadInstance.start();
}
}
@Override
public void run() {
while ( true ) {
try { Thread.sleep( 2000 ); } catch (
InterruptedException ie ) {}
}
}
}
and call DaemonThread.startThread(); within the process() method.
After CPE signals collectionProcesscomplete() the application does not exit.
The reason: in org.apache.uima.collection.impl.cpm.engine.CPMEngine a
threadGroupDestroyer thread is created (line 2522) which waits for threads to
die. Since it does not check for daemon threads it counts them as normal
threads to wait for and thus it waits forever (this can be seen with kill -3
PID to get a JAVA stack trace of all threads under UNIX).
A workaround would be to put the daemon thread in another ThreadGroup. In the
example if you create the tread with
ThreadGroup parent =
Thread.currentThread().getThreadGroup();
while ( parent.getParent() != null )
parent = parent.getParent();
threadInstance = new Thread( parent, new
DaemonThread(), "TestDaemon" );
(in the top most thread group) the CPE exits normally.
However this is not possible with closed source libraries.
Thus the threadGroupDestroyer must test for daemon threads. Furthermore the
used group.activeCount() (in
org.apache.uima.collection.impl.cpm.engine.CPMEngine) should only be used for
information purposes - as the javadoc states - not for relying on it as a loop
parameter.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
