[concurrency-interest] ThreadPoolExecutors and System.exit
davidcholmes at aapt.net.au
Thu Dec 31 20:02:15 EST 2009
Does ctrl-/ produce a thread dump showing where the threads are? During a
shutdown there are sufficient system threads active that your app threads
may not get a chance to progress further. Once the shutdown reaches a
certain stage then all application threads (daemon or non-daemon) will stop
executing as the VM comes to a safepoint for termination.
Why do you expect processing to continue, do you use a shutdown hook that
takes a long time to run?
From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Paulo Levi
Sent: Thursday, 31 December 2009 11:38 AM
To: concurrency-interest at cs.oswego.edu
Subject: [concurrency-interest] ThreadPoolExecutors and System.exit
I have a TPE subclass and i'm seeing (disturbingly only on some dual core
processors) a hang when the application is closed and there are lots of
tasks to be processed. Specifically no-more tasks appear to be processed,
but the (daemon) threads are still alive at the time shutdown hooks are
(daemon, alive, not interrupted).
Threadfactory used by the subclass creates daemon threads, and the class
is configurated with a keepAliveTime > 0 in this case (to reuse the threads)
and a LIFO queue instead of the normal one.
I appear to be able to avoid it with a shutdown hook, but i would like to
know if all ThreadPoolExecutors are vulnerable to this.
(disturbingly too, after this, the debugger says the java process is
closed, however windows task manager disagrees).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest