[
https://issues.jboss.org/browse/WFLY-3225?page=com.atlassian.jira.plugin....
]
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