Joerg Hoh created SLING-12128:
---------------------------------
Summary: Threadpools never shrink back to min-threads
Key: SLING-12128
URL: https://issues.apache.org/jira/browse/SLING-12128
Project: Sling
Issue Type: Task
Components: Commons
Affects Versions: Commons Threads 3.2.22
Reporter: Joerg Hoh
I made the observation that threadpools with an unbounded queue (default) which
are managed by Sling Threadpools never shrink to the configured minimum of
threads, but consistently have all threads running, even if no work needs to be
done:
{noformat:title=Output of the Webconsole Printer}
Pool ThreadPool-7cfefa0b-49bc-402f-aaca-2e5b2a21b986
- used : true
- min pool size : 5
- max pool size : 10
- queue size : -1
- keep alive time : 60000
- block policy : RUN
- priority : NORM
- shutdown graceful : true
- shutdown wait time : -1
- daemon : false
- active count : 0
- completed task count : 0
- core pool size : 10
- largest pool size : 0
- maximum pool size : 10
- pool size : 0
- task count : 0
{noformat}
Here the "min pool size" is set to 5, but the Core Pool Size of the JDK's
ThreadPoolExecutor is set to 10.
This seems to be caused by SLING-7407
([Github|https://github.com/apache/sling-org-apache-sling-commons-threads/blob/49074141ecec676804e3d9b511ad87ca4e67fabd/src/main/java/org/apache/sling/commons/threads/impl/DefaultThreadPool.java#L114]).
We should improve that so that the CorePoolSize of the ThreadPoolExecutor is
actually set to the configured min value, even if the queue is unbounded. This
allows the threadpool to properly downscale if the threads are not needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
