tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Laurent <>
Subject Re: Need advice to notify StandardExecutor when a webapp is stopped
Date Thu, 06 May 2010 21:20:53 GMT
I finally proposed a patch for trunk in
for this. Thanks for reviewing it...


On 30 avr. 2010, at 18:27, Sylvain Laurent wrote:

> On 30 avr. 2010, at 00:01, Pid wrote:
>> Are you saying that you want to stop processing requests each time a
>> webapp gets restarted, or that the thread pool is refreshed by
>> sequentially killing each thread and recreating it?
> Something in between : I create a new pool with the same characteristics as the current
one, make it the current pool so that new requests are served by the new pool, then cleanly
shut the old pool down. When calling ThreadPoolExecutor.shutdown(), it gracefully terminates
all threads in the pool after its associated TaskQueue is empty : Idle threads stop immediately
(and not sequentially), busy threads continue processing their current request. If the TaskQueue
is not empty, it means that there are no idle threads, and so busy threads will continue processing
tasks in the queue until it becomes empty.
> The renewThreads looks like (in StandardThreadExecutor) :
> 	public void renewThreads() {
> 		ThreadPoolExecutor oldExecutor;
> 		synchronized (executorLock) { // to avoid renewing threads concurrently
> 			oldExecutor = executor;
> 			ThreadPoolExecutor newExecutor=new ThreadPoolExecutor(getMinSpareThreads(),
> 					getMaxThreads(), maxIdleTime, TimeUnit.MILLISECONDS,
> 					taskqueue, oldExecutor.getThreadFactory());
> 			executor = newExecutor;
> 			taskqueue.setParent(executor);
> 		}
> 		oldExecutor.shutdown();
> 		//we don't wait for termination of the old pool, threads will terminate when their
work is done
> 	}
> I marked StandardThreadExecutor.executor and TaskQueue.parent as volatile to propagate
the change of executor instance to other threads without synchronizing threads.
> An improvement I can do is to pre-start some "core" threads in the new pool before making
it active. It would reduce the performance impact on the next few requests.
> Sylvain

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message