[jboss-jira] [JBoss JIRA] (WFCORE-1539) Consider doing management remoting write interaction using a fixed size pool

[Brian Stansberry (JIRA)]

Brian Stansberry created WFCORE-1539:
----------------------------------------

             Summary: Consider doing management remoting write interaction using a fixed size pool
                 Key: WFCORE-1539
                 URL: https://issues.jboss.org/browse/WFCORE-1539
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


Since the work on WFLY-3090 a lot of the management layer's work of writing to remoting has been done asynchronously to the calling thread using the thread pool associated with the ManagementRequestContext. In practice this pool is the unbounded HostControllerExecutorService or ServerExecutorService. But unbounded queues may be inefficient for how some caching strategies work, so using a fixed pool for this may be better. See WFCORE-1528 for a caching problem in undertow, which we don't believe remoting has, but which is the kind of fragility we want to avoid.

The following are the uses of executors with the ManagementRequestContext. The first two methods use the executor associated with the MRC, i.e. HostControllerExecutorService or ServerExecutorService. The 3rd method the caller provides an executor. The items marked with 2 stars are unusual in some way but probably ok for a fixed pool, those with 4 stars we definitely don't want a fixed pool, and 3 stars need a bit more thought. The others should be ok with a fixed pool.

executeAsync(AsyncTask task, boolean cancellable)

CancelAsyncRequestHandler L330 -- async sends the response
ModelControllerClientOperationHandler.CompletedCallback L287 -- sends final response
TransactionalProtocolClientImpl.ExecuteRequest L161 -- sends the main *request* async
TransactionalProtocolClientImpl.CompleteTxRequest L265 -- sends the commit/rollback *request* async
TransactionalProtocolOperationHandler L602 -- multiple uses
 ExecuteRequestContext L557 -- completed
 ExecuteRequestContext L420 -- failed
 ExecuteRequestContext L532 -- failed
 ExecuteRequestContext L467 -- prepared
** TransactionalProtocolOperationHandler.ExecuteRequestContext L578 -- actually does the cancel
** HostControllerConnection.ServerReconnectRequest L311 -- calls done on ResultHandler (I see no reason this needs to be async)


executeAsync(final AsyncTask<A> task)

ResponseAttachmentInputStreamSupport.AbstractAttachmentHandler L275 -- reads stream, writes out to remoting
TransactionalProtocolClientImpl.ReadAttachmentInputStreamRequestHandler L335 -- reads stream, writes out to remoting
TransactionalProtocolOperationHandler.ExecuteRequestHandler L170 -- executes the request
AbstractModelControllerClient.ReadAttachmentInputStreamRequestHandler L211 -- reads stream, writes out to remoting
RemoteFileRequestAndHandler L152 -- writes the response
**** RemoteDomainConnection.HostControllerConnectRequest L385 -- resolve subsystem versions, send to DC
**** RemoteDomainConnection.RegisterSubsystemsRequest L450 -- apply domain model (which surely takes the lock)
**** ServerToHostProtocolHandler.ServerReconnectRequestHandler L262 -- takes lock! calls ServerInventory.serverReconnected
*** ServerToHostProtocolHandler.ServerStartedHandler L335 -- invokes the server inventory, serverStarted/StartFailed

executeAsync(final AsyncTask<A> task, Executor executor)

ModelControllerClientOperationHandler.ExecuteRequestHandler L142 -- execute request using a fixed size pool
RemoteFileRequestAndHandler L154 -- read and write the file using an executor provided to the constructor
  this executor is null except on a DC where it is the HostControllerExecutorService
**** HostControllerRegistrationHandler.InitiateRegistrationHandler L231 -- registration using HostControllerExecutorService
**** ServerToHostProtocolHandler.ServerRegistrationRequestHandler L177 -- server reg using an Executors.singleThreadExecutor

Given the propenderance of cases where a fixed pool is ok, if we choose to do this task perhaps the simple solution is to make the MRC pool fixed by default and for cases where that is inappropriate provide the caller with a ref to HostControllerExecutorService or ServerExecutorService and lets them pass it in to the MRC method as a param.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)