Hello, On 26 oct. 2011, at 17:55, Rohit Kelapure wrote:
> * Reposting from the dev list as advised * > > Dear All, > > After going through the thread renewal code in > /tomcat-8.0.x/java/org/apache/tomcat/util/threads/TaskQueue.java , > /tomcat-8.0.x/java/org/apache/tomcat/util/threads/ThreadPoolExecutor.java > and the bug (Improve ThreadLocal memory leak clean-up) > https://issues.apache.org/bugzilla/show_bug.cgi?id=49159 I had the > following questions- > > 1. Once the thread pool has been renewed after No. of active threads > in pool * max (threadKeepAliveTimeout, longestRequest+ > threadRenewalDelay) seconds, why does the ThreadPoolExecutor still > keep paying the price of thread renewal. ? > After org.apache.tomcat.util.threads.ThreadPoolExecutor.threadRenewalDelay > is set to 1000L it never goes back to -1. Ideally once the all the > threads in the threadpool is renewed we should revert the > threadRenewalDelay back to -1 and NOT call > ThreadPoolExecutor.currentThreadShouldBeStopped()/ThreadPoolExecutor.stopCurrentThreadIfNeeded() > in TaskQueue.poll(long, TimeUnit) or TaskQueue.take(). > Is this because we are never quite sure as to when *all* of the > threads in the pool have been renewed ? Yes. threadRenewalDelay is a configuration parameter of the ThreadPoolExecutor and its value never changes at runtime (unless you play with JMX). The thing is that it may take a long time to renew all the threads of the pool because there might be very long requests. Besides, a second renewal can be triggered (i.e. another webapp being stopped) while some threads have not been renewed yet after the first renewal was asked. By comparing the timestamps of when the thread was created and when the last renewal was triggered, we are sure that all threads are eventually renewed (provided they are returned to the pool). > > 2. Does the thread renewal approach scale under load (i.e. all threads > in the pool busy servicing requests and CPU close to 90%) ? Is it > meant for production deployments ? Yes, it was meant for both development and production and is enabled by default. When I was developing it I performed some load tests with JMeter to check that there is no functional impact while threads are being renewed, but I did not measure the performance impact of recreating new threads. Anyway, threadRenewalDelay is here to throttle the rate of renewal, so that not all threads are re-created at the same time, thus the performance impact should be negligible (and configurable). > > 3. How about threads that are servicing long running HTTP Keep-alive > connections that never let the thread return to the pool. Are these > threads renewed before the server is stopped. With tomcat 6 (and the BIO connector, I don't know for others), threads were tied to the TCP connection as you describe, so that they were not returned to the pool if the connection was kept alive. But kee-palive is not eternal, the number of requests is limited and there's a timeout if the client does not send a new request for some time. From tomcat 7 (with the BIO connector at least), threads are decoupled from TCP connections, so that even with keep-alive, threads are returned to the pool after servicing each request. So, in this case threads are newed if needed. Sylvain --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
