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

Reply via email to