[jboss-jira] [JBoss JIRA] (WFLY-3225) Rationalization of management thread pools

[Brian Stansberry (JIRA)]

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

Brian Stansberry commented on WFLY-3225:
----------------------------------------

Yes, that would be better, and what I originally wanted to do. 

The end-user request case uses 4 threads and then a large queue (probably too large) to queue up other messages that come in. The other pool has no queue. I considered having the end user requests just go into a queue (inserted by the remoting thread) and then have the regular pool process the queue, with only 4 threads max doing that work.

But when I looked at it would have been quite painful to implement; requiring bug-prone refactoring of how tasks are handled, particularly exception handling. So since right now there are really two cases, the concurrency limited one for end-user requests, and then the "everything" else one, right now I'm going for two pools. I'd like to double back at some point though and get it down to one pool.
                
> Rationalization of management thread pools
> ------------------------------------------
>
>                 Key: WFLY-3225
>                 URL: https://issues.jboss.org/browse/WFLY-3225
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 9.0.0.CR1
>
>
> There are a number thread pools being created related to management request handling that are redundant and could be replaced by the ServerService-created or HostControllerService-created pool:
> RemoteDomainConnectionService - Executors.newCachedThreadPool
> HostControllerConnectionService - Executors.newCachedThreadPool
> DomainModelControllerService - Executors.newCachedThreadPool
> MasterDomainControllerOperationHandlerService.slaveRequestExecutor (1 core thread, unlimited max threads, no queue -- essentially same as Executors.newCachedThreadPool)
> I believe these specialized pools were created because AbstractModelControllerOperationHandlerFactoryService uses a 4 thread pool with a large queue. That's appropriate for throttling threads used for end user requests, but is inappropriate for internal tasks where such throttling risks thread starvation and deadlock. So, this fix will shift the end user request handling to a specialized limited pool and then all the other tasks can use the general pool.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira