Understanding about Tomcat thread pool and tomcat Thread Pool

Understanding about Tomcat thread pool and tomcat Thread Pool
By default, Tomcat creates a bound thread pool for each connector (the maximum number of threads is 200 ). In most cases, you do not need to change this configuration (unless you increase the maximum number of threads to meet high load requirements ). However, Tomcat prefers to cache objects such as PageContext and tag cache in the thread-local context of each worker thread. For this reason, you expect Tomcat to turn off the thread to clear some memory. In addition, if each connector maintains its own thread pool, it is more difficult to set a maximum value (number of threads) based on the server's capacity. The answer to these questions is to use a shared executor.
By making all connectors use the same shared executor, you can configure the maximum number of concurrent requests that the entire application can carry. The executor also enables the thread pool to expand during idle hours and busy hours. At least theoretically...
Org. apache. catalina. core. StandardThreadExecutor
By default, the standard and built-in actuator used by Tomcat are StandardThreadExecutor. Access the configuration document: http://tomcat.apache.org/tomcat-6.0-doc/config/executor.html. There is an improper parameter "maxIdleTime" in these configuration options. The following are some things you need to know about the closing of standard executors and Idle threads.
The standard executor internally uses a java. util. concurrent. ThreadPoolExecutor. It works through a thread pool with a variable size. Once these threads complete a task, they will wait for a blocking queue until a new task comes in. Or until it waits for a set time, it will "time out" and the thread will be closed. The key point here is that the first thread that completes a task will first be assigned a new task, and the thread pool follows a first-in-first-out (FIFO) mode. Always pay attention to this when we check how it will affect Tomcat actuators.
MaxIdleTime is actually minIdleTime
Because of the FIFO behavior of Java ThreadPoolExecutor, each thread will wait for the minimum "maxIdleTime" time to accept new tasks before it may be disabled. In addition, because of the FIFO action of the thread pool, the first thread that enters the idle state will be preferentially assigned new tasks, therefore, before it is disabled, it also needs to wait for maxIdleTime without any request to enter. The impact of this is that the executor cannot actually set the appropriate average load (concurrent requests) size for the thread pool, and it will allocate this size at a higher request speed. It seems that there is no difference, but for web servers, the impact is huge. For example, 40 requests come in at the same time. The thread pool will be extended to 40 to adapt to this load. In a later period, only one request is entered at a time. For example, it takes 500 MS to end the execution of each request, which means that it takes 20 seconds to execute the thread in the entire thread pool again (Remember, FIFO) in the next period ). Unless you set your maxIdleTime to less than 20 seconds, the thread pool will keep holding 40 threads, even if your concurrency never exceeds 1. However, you do not want to set your maxIdleTime too small-this will cause you to be at risk of being disabled too quickly.
Conclusion
To match the average load, rather than the rate at which a request enters, an expected thread pool behavior should be obtained. It is more appropriate that the executor should be based on a post-first-out (LIFO) mode. If the thread pool is able to allocate tasks with the least Idle threads in priority, the server will be able to close the threads (in a more predictable way) at a lower load stage ). In the simple example above, the initial load after 40 is maintained at 1 for a period of time, a lifo thread pool can be adjusted to 1 after the maxIdleTime stage. Of course, you are not always required to use this strategy, but if your goal is to minimize the resources held by Tomcat, it is unfortunate that the standard executor may not be what you expected.
Link to the original article: https://papweb.wordpress.com/2010/10/30/understanding-tomcat-executor-thread-pooling /.