[jboss-jira] [JBoss JIRA] (WFCORE-2793) Get rid of the "DeploymentScanner Threads" pool

[Brian Stansberry (JIRA)]

    [ https://issues.jboss.org/browse/WFCORE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404639#comment-13404639 ] 

Brian Stansberry commented on WFCORE-2793:
------------------------------------------

Skipping queued content repo cleaner tasks is fine; the repo cleaner can run the next time the server is booted.

ResponseAttachmentInputStreamSupport.shutdown() cleans up the input streams in server stop scenarios. The scheduled task is to clean them up if the server isn't stopping. So not executing queued tasks is fine.

TempFileProvider.deleteTask schedules an attempt to delete a file if it cannot be deleted immediately. Since the threads in the pool are non-daemon there is no guarantee this will happen following shutdown (probably won't). *However, following a reload, where the daemon threads live on, perhaps not running these would have negative effects; i.e. the reload eliminates whatever was preventing the initial delete, so then later the DeleteTask can succeed.*

The deployment scanner uses its executor as follows:

DefaultDeploymentOperations -- here it's not using it for scheduled tasks, and the non-scheduled ServerService.ServerExecutorService could be used. The pool is used to create a LocalModelControllerClient. So no relevance to scheduled task shutdown.

FileSystemDeploymentService -- the main thing...

BootTimeScannerDeployment.deploy(...) uses it to execute an async task, but it could probably be given ServerService.ServerExecutorService in its constructor and the Executor param dropped. Or FilesystemDeploymentService can pass in the ServerService.ServerExecutorService.

FilesystemDeploymentService.startScan() executes DeploymentScanRunnable. There is no reason to run one of these if from the scheduled executor queue, as it will just see that 'scanEnabled != true' and return.

singleScan() executes ManualScan. This is not a delayed task, and ServerService.ServerExecutorService could handle it.

scan() submits another DeploymentScanRunnable if the first run returned Status.RETRY, i.e. there was incompletely copied content in the deployments dir. This basically is to try again quickly in order to see if the copy is complete. There is no reason this needs to run if the scheduled executor is shut down. The server is being stopped; there's no point trying to deploy to it.

*Summary*

The only negative I see to simply discarding queued tasks on scheduled executor shutdown is the case of a reload, where TempFileProvider.deleteTask currently may eventually run and do some cleanup.

> 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)