[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:comment-tabpanel&focusedCommentId=13305160#comment-13305160 ] 

Yeray Santana Borges commented on WFCORE-1791:
----------------------------------------------

It seems the operation-id is sent back to the HC in this method: HostControllerConnection.ServerRegisterRequest.sendRequest. As far as I have been able to check, this is the sequence which enables the operation-id being sent back:

# Reload is executed in a domain mode, so HC sends the current operation-id in the reload operation to the managed server(s)
# On server(s) side, ServerDomainProcessReloadHandler is executed which updates the static instance variable DomainServerCommunicationServices.initialOperationID
# Server(s) is reloaded, the root service for an application server process is ApplicationServerService, its start() method is then invoked which activates two service activators: DomainServerCommunicationServices and an anonymous service activator created in ServerStartTask
# DomainServerCommunicationServices.activate is invoked which creates a new HostControllerConnectionService and installs it, so its HostControllerConnectionService.start method is invoked which creates a new HostControllerConnection instance. This instance is the instance used to send the operation-id back to the HC. In this point the HostControllerConnection has the operation-id updated in point 2) by the reload operation on server side.
# The anonymous service activator in ServerStartTask class is activated too. This class installs the ServerBootOperationsService service. This service in L68 invokes HostControllerClient.resolveBootUpdates which invokes HostControllerConnection.openConnection. The connection is then opened using ServerRegisterRequest which sends the operation-id the HC in ServerRegisterRequest.sendRequest. 
# The server is registered then by the HC executing the register operation and without blocking since it has the correct operation-id received before.


> 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)