Brian Stansberry created WFCORE-3597: ---------------------------------------- Summary: Defer sending response to reload op until the ProcessReloadHandler has changed the process state Key: WFCORE-3597 URL: https://issues.jboss.org/browse/WFCORE-3597 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Currently the response to the reload op goes out to the client as soon as the op commits, not waiting for the op to complete. It can't wait for the op to complete, because op completion may not occur before the service managing the connection to the client is stopped. But sending the response on commit is too early, as the ProcessReloadHandler hasn't even begun the reload yet. If a client receives that response and immediately begins polling for the server in RUNNING state (i.e. completed reload) there is a race where it's possible the client sees the server as RUNNING *before* the reload has begun, rather than after. https://github.com/wildfly/wildfly-core/pull/3098 for WFCORE-3594 helps mitigate the chances of this by putting the process in STOPPING state a bit faster. But an ultimate solution requires the ProcessReloadHandler being able to signal when the response should go out. I think this can be done via an OperationContext attachment that the current code that sends the response on commit would attach. -- This message was sent by Atlassian JIRA (v7.5.0#75005)