[
https://issues.jboss.org/browse/WFCORE-2793?page=com.atlassian.jira.plugi...
]
Brian Stansberry commented on WFCORE-2793:
------------------------------------------
An important thing to consider is the lifecycle of the pool and what happens to scheduled
tasks when the pool is stopped.
The ServerService.ServerScheduledExecutorService uses non-daemon threads. The service stop
does a simple shutdown(), with no blocking for completion. The pool has
setExecuteExistingDelayedTasksAfterShutdownPolicy(false) set so following the shutdown
call any tasks not started will be discarded. But tasks that are in progress will
continue. Since the threads are non-daemon they should keep the vm alive until completed.
ServerDeploymentRepository-temp-threads uses daemon threads. The service stop does a
simple shutdown(), with no blocking for completion. The pool *does not* have
setExecuteExistingDelayedTasksAfterShutdownPolicy(false) set so following the shutdown
call any tasks not started will still be executed. But the fact the threads are daemon
threads means the VM will exit despite tasks being queued or in progress.
The deployment-scanner uses non-daemon threads. The service stop does a simple shutdown(),
with no blocking for completion. The pool *does not* have
setExecuteExistingDelayedTasksAfterShutdownPolicy(false) set so following the shutdown
call any tasks not started will still be executed. Since the threads are non-daemon they
should keep the vm alive until completed.
Get rid of the "DeploymentScanner Threads" pool
-----------------------------------------------
Key: WFCORE-2793
URL:
https://issues.jboss.org/browse/WFCORE-2793
Project: WildFly Core
Issue Type: Bug
Components: Deployment Scanner, Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Look into whether we can consolidate thread usage for scheduled tasks.
1) Get rid of the "DeploymentScanner Threads" pool
The deployment scanner can use the kernel scheduled executor. I'm a bit reluctant in
general to allow use of this pool by subsystems as scheduled executors have a fixed size
pool, so arbitrary usage by subsystems can result in tying up all the threads doing long
running tasks and undesirable behavior. But deployment-scanner is "kernel-ish
enough" that I think it's ok.
This will remove 2 threads.
The server scheduled executor has 4 threads which is actually pretty high given the very
limited usage of it. So I'll consider narrowing it down.
The big problem with using the server scheduled executor is tying up its threads long
running tasks, which the scanner does do. What i'll probably do is just use the
scheduled executor to trigger a task which then submits a task on the main ServerService
thread pool (which is unlimited in size.)
Perhaps I'll abstract this kind of usage pattern into a service, and make that
service a generally available kernel capability.
2) Get rid of the "ServerDeploymentRepository-temp-threads" pool
This one is used by DeploymentMountProvider to do file cleanup. Similar discussion
applies.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)