[jboss-jira] [JBoss JIRA] (WFCORE-4596) Write lock is acquired reading patching resource using include-runtime

[Yeray Borges (Jira)]

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

Yeray Borges updated WFCORE-4596:
---------------------------------
    Description: 
This is initially created as a bug but it needs first some investigation to discover if it is really necessary to acquire the write lock when the patching resource is read. If it is unnecessary, we should remove this need.

The following operation is acquiring the write lock:

{noformat}
/host=slave/core-service=patching:read-resource(include-runtime=true) 
{noformat}

It potentially will block if there is any other operation that has already acquired the lock. One consequence found due to this issue was HAL could block and hang if an HC is starting and the user clicks on 'Patching' menu entry. It was fixed in HAL, where an HC being restarted is no longer shown in the Patching menu.

The main problem seems to be in PatchStreamResourceOperationStepHandler, which is the parent handler used for the handlers that manage patching operations. This parent handler is always acquiring the write lock.


  was:
This is initially created as a bug but it needs first some investigation to discover if it is really necessary to acquire the write lock when the patching resource is read. If it is unnecessary, we should remove this need.

The following operation is acquiring the write lock:

{noformat}
/host=slave/core-service=patching:read-resource(include-runtime=true) 
{noformat}

It potentially will block if there is any other operation which has already acquired the lock. One consequence found due to this issue was HAL could block and hang if an HC is starting and the user clicks on 'Patching' menu entry. It was fixed in HAL, where HS being restarted are no longer shown in the Patching menu.

The main problem seems to be in PatchStreamResourceOperationStepHandler, which is the parent handler used for the handlers that manage patching operations. This parent handler is always acquiring the write lock.




> Write lock is acquired reading patching resource using include-runtime
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-4596
>                 URL: https://issues.jboss.org/browse/WFCORE-4596
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Patching 
>            Reporter: Yeray Borges
>            Assignee: Yeray Borges
>            Priority: Major
>
> This is initially created as a bug but it needs first some investigation to discover if it is really necessary to acquire the write lock when the patching resource is read. If it is unnecessary, we should remove this need.
> The following operation is acquiring the write lock:
> {noformat}
> /host=slave/core-service=patching:read-resource(include-runtime=true) 
> {noformat}
> It potentially will block if there is any other operation that has already acquired the lock. One consequence found due to this issue was HAL could block and hang if an HC is starting and the user clicks on 'Patching' menu entry. It was fixed in HAL, where an HC being restarted is no longer shown in the Patching menu.
> The main problem seems to be in PatchStreamResourceOperationStepHandler, which is the parent handler used for the handlers that manage patching operations. This parent handler is always acquiring the write lock.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)