Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-3225

Rationalization of management thread pools

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Done
    • Icon: Major Major
    • 8.1.0.CR1, 8.1.0.Final
    • None
    • Management
    • None

      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.

              bstansbe@redhat.com Brian Stansberry
              bstansbe@redhat.com Brian Stansberry
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: