[jboss-jira] [JBoss JIRA] (WFCORE-3634) ActiveOperationImpl should remove the operation from the handler before signalling the result handler

[Brian Stansberry (JIRA)]

     [ https://issues.jboss.org/browse/WFCORE-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-3634:
----------------------------------------

    Assignee:     (was: Brian Stansberry)


> ActiveOperationImpl should remove the operation from the handler before signalling the result handler
> -----------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3634
>                 URL: https://issues.jboss.org/browse/WFCORE-3634
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Management
>            Reporter: Brian Stansberry
>            Priority: Optional
>
> Caution: this is a theoretical solution to a problem.
> I'm seeing a fairly frequent problem with the use of org.wildfly.core.testrunner.Server.reload() where the reload is proceeding but the server log shows the following, followed by various undesirable things and a test failure of one sort or another:
> {code}
> &amp#27;[0m&amp#27;[0m07:50:27,581 INFO  [org.jboss.as.protocol] (management I/O-2) WFLYPRT0057:  cancelled task by interrupting thread Thread[management-handler-thread - 1,5,management-handler-thread]
> {code}
> I believe the issue is that Server.executeReload is closing the client in a finally block immediately after reading the response to reload. But the server sends the response to reload *early* so on the server side the op is still in progress. The client-side close of the client is resulting in cancellation of that still in-progress op.
> But why is the close of the client causing cancellation? The client has received the response; why is it still tracking the operation?  My theory is that the ResultHandler created by ActiveOperationImpl is publishing the result (or failure) before it removes the active operation from tracking in a finally block. Doing this in the opposite order would mean the active op would be cleared before the result is published.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)