]
Brian Stansberry moved WFLY-6649 to WFCORE-2149:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-2149 (was: WFLY-6649)
Component/s: IO
(was: IO)
Affects Version/s: (was: 10.0.0.Final)
Io subsystem worker pool threads cannot die even if task-keepalive is
specified
-------------------------------------------------------------------------------
Key: WFCORE-2149
URL:
https://issues.jboss.org/browse/WFCORE-2149
Project: WildFly Core
Issue Type: Bug
Components: IO
Reporter: Mathieu Lachance
Assignee: Jason Greene
The Wildlfy io subsystem should allow to set thread keep alive time as documented in
wildfly_io_1.1.xsd:
{code}
<xs:attribute name="task-keepalive" type="xs:int"
default="60"/>
{code}
Though when you have a look at the XNIO implementation i.e.
https://github.com/xnio/xnio/blob/f1bd055381436683789c7e69a3f6455b7141ad2...:
{code}
taskPool = new TaskPool(
threadCount, // ignore core threads setting, always fill to max
threadCount,
optionMap.get(Options.WORKER_TASK_KEEPALIVE, 60000), TimeUnit.MILLISECONDS,
taskQueue,
new WorkerThreadFactory(threadGroup, optionMap, markThreadAsDaemon),
new ThreadPoolExecutor.AbortPolicy());
final class TaskPool extends ThreadPoolExecutor {
TaskPool(final int corePoolSize, final int maximumPoolSize, final long
keepAliveTime, final TimeUnit unit, final BlockingQueue<Runnable> workQueue, final
ThreadFactory threadFactory, final RejectedExecutionHandler handler) {
super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue,
threadFactory, handler);
}
protected void terminated() {
taskPoolTerminated();
}
}
{code}
The created TaskPool/ThreadPoolExecutor will have both the core and max thread size
equals. By setting them both equals, means that if
ThreadPoolExecutor#allowCoreThreadTimeOut is not true, no thread will ever be able to die
even if there's a keepAliveTime set.
I think previously there's was a setting to set the actual amount of "core"
thread pool but I think it was removed in Wildfly 9. But from an outsider, it is not
really clear reading the code that this is really the case.
That said, I think having either that setting back or setting the
"allowCoreThreadTimeOut" set to true will fix the issue.
Not letting thread die:
# is a "waste" of resource
# can lead to some ThreadLocal grows out of proportions (even if bad practice)
Also, the documentation should be more precise to specify the time unit that will be used
when configuring the keep alive time; from what I understand, it should state
milliseconds.