[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 updated WFCORE-3634:
-------------------------------------
    Priority: Optional  (was: Major)


Switching this to optional and I'll probably reject it. 

Turns out this isn't what was causing the failures I was seeing.

And closing a RemotingModelControllerClient, before any active operations are cancelled, the channel to the server is closed, which is going to cause the server-side channel to close, affecting active operations.

So this change is valid in a theoretical sense but will likely not have any practical benefit.

Fix is at https://github.com/bstansberry/wildfly-core/tree/WFCORE-3634

> 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: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: 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)