[ https://issues.jboss.org/browse/WFCORE-1539?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1539: ------------------------------------- Description: 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. {code} 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 {code} Given the preponderance 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. was: 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)