[jboss-jira] [JBoss JIRA] (WFCORE-1791) Strange operation-id handling in domain server reload execution

[Yeray Santana Borges (JIRA)]

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

Yeray Santana Borges reassigned WFCORE-1791:
--------------------------------------------

    Assignee: Yeray Santana Borges


> Strange operation-id handling in domain server reload execution
> ---------------------------------------------------------------
>
>                 Key: WFCORE-1791
>                 URL: https://issues.jboss.org/browse/WFCORE-1791
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Yeray Santana Borges
>            Priority: Minor
>
> When the HC sends a reload op to a managed server it includes an undocumented "operation-id" parameter. But, I don’t see how it is used with a reload. When it was added to the code the intent clearly was that it would be used, but now at least is not. ServerDomainProcessReloadHandler reads it from the op and sets DomainServerCommunicationServices.initialOperationId, but that field is only read when HostControllerConnectionService is instantiated. HostControllerConnectionService then caches the value in a final field. A reload does not result in a new instantiation of HostControllerConnectionService; that object is only instantiated during initial process boot when ServerStartTask is unmarshaled from stdin and run. So changing the DomainServerCommunicationServices.initialOperationId in a reload should do nothing.
> https://github.com/wildfly/wildfly-core/commit/302949cf60823d8aa3989d74df15c88cc89ffd90 is the initial commit when this update of the id in reload was added in. The intent was that by providing this id, when the reloading server connects to the HC to get the boot ops, that read of boot ops would be able to "join" any active operation that triggered the reload, and thus would not have to block waiting for that operation to complete. 
> Afaict, if the "blocking" param on an op like /host=x/server[-config]=y:reload is set to 'true' the op should deadlock. On the HC, ServerReloadHandler will acquire the exclusive lock by calling context.getServiceRegistry(true). Then ServerInventoryImpl.reloadServer will block waiting for the server to reach STARTED state. But the server won't reach that because it's registration request will not be able to acquire the HC lock.
> Task here is to
> 1) Confirm the above and then 
> 2) Either
> a) get the operation-id propagated
> b) or rip the operation-id bit out of reload because investigation showed it was not needed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)