[concurrency-interest] "Best practice" for ThreadPool creation/run-down

Peter Kovacs peter.kovacs.1.0rc at gmail.com
Tue Jan 8 09:57:06 EST 2008


I am implementing multi-threaded routines in a Java library to be used
via Java API. By default, my library "silently" creates the ThreadPool
it needs. (The library provides API for the user to use whatever
Executor it wishes to override the default ThreadPool, but the point
here is the default behavior.) The thing is that the default
keepAliveTime of the TP is 60 seconds which is (I think) fine. As the
application is wound down, however, the threads in the pool are
waiting until their keepAliveTimes expire. That's is fine so far: I
can provide a handle to shut the TP down without delay at the end of
the application. But there is this assimmetry which bugs me: I
silently create something which then needs to be shutdown explicitly
by the innocent user of the API. Am I the only one to feel
uncomfortable with this? What is recommended procedure in such cases?

I've just checked that System.exit(...) doesn't wait for the thread
pool to wind down. Does this make a difference to my problem? Can I
rely on the application developer calling System.exit(...)?

Also, does anyone have it on top their head: how does the existence of
non-daemon threads affect the termination of an application-context in
an application container such as Tomcat? (I. e. the case when my
library is used in a WEB application.)

Thanks a lot,

More information about the Concurrency-interest mailing list