[jboss-jira] [JBoss JIRA] (WFCORE-1009) Treat intra-domain transactional ":reload" and ":shutdown" requests similarly to how we handle end user requests

Treat intra-domain transactional ":reload" and ":shutdown" requests similarly to how we handle end user requests ---------------------------------------------------------------------------------------------------------------- Key: WFCORE-1009 URL: https://issues.jboss.org/browse/WFCORE-1009 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Brian Stansberry Assignee: ehsavoie Hugonnet ModelControllerClientOperationHandler.ExecuteRequestHandler has special logic for the ":reload" op such that once the operation notifies that it is prepared, it immediately sends the final "success" result to the client, not waiting for the op execution to return to send it. This allows the response to go out to the client before the reload starts shutting down services. WFCORE-1008 proposes expanding this to the ":shutdown" operation as well. This JIRA proposes expanding this to the TransactionalProtocolOperationHandler used for intra-domain process requests as well. The implementation here would be slightly different in that the response to the prepared notification from the op would be unchanged. What would change would be the handling of the tx commit coming from the client. The tx commit message handling would send the response instead of waiting for the original op to complete. The client side state related to the status of the reloading/shutting down slave HC or server should be fine. A master HC's tracking of slaves is unaffected by proxying a reload or shutdown op; it monitors the master<->slave comm channel to track the slave. Same thing for an HC reloading a server. For the case where an HC is stopping a server by sending a ":shutdown" request, the response to the request puts the HC's view of the server's state into InternalState.PROCESS_STOPPING. This state is valid as soon as the HC commits the ":shutdown" request, so this JIRA is consistent with that handling. (Note: This special handling of ":reload" isn't a perfect thing, as it only covers the direct use of the ":reload" op. It doesn't cover things like a reload as a step in a composite. For the composite case, we need to give the step handlers for the other steps a chance to run any ResultHandlers they have registered and fix up the response before we send it back, so we can't just ignore that part of the execution.)