[
https://issues.jboss.org/browse/WFCORE-1616?page=com.atlassian.jira.plugi...
]
Brian Stansberry updated WFCORE-1616:
-------------------------------------
Description:
ServerSuspendHandler is calling OperationContext.completeStep() and passing in a rollback
handler from a org.jboss.as.server.suspend.OperationListener that may be invoked by a
different thread. The OperationContext is not intended to be invoked from multiple threads
in this way.
3 things can happen with this setup:
1) There is no activity preventing suspend, so the suspend controller immediately calls
back to the OperationListener on the thread that's handling the operation. So then
things work fine.
2) There is something that prevents synchronous suspend (i.e. user activity) so then the
OperationListener gets invoked later by another thread. The completeStep call registers a
rollback handler that will never get called because the op is already done. No harm, no
foul unless the operation rolled back.
3) Same as 2) but the OperationListener gets invoked later by another thread while the
mgmt op is still executing and somehow something goes wrong, since
AbstractOperationContext.Step is not written for concurrent modification.
was:
ServerSuspendHandler is calling OperationContext.completeStep() and passing in a rollback
handler from a org.jboss.as.server.suspend.OperationListener that may be invoked by a
different thread. The OperationContext is not intended to be invoked from multiple threads
in this way.
4 things can happen with this setup:
1) There is no activity preventing suspend, so the suspend controller immediately calls
back to the OperationListener on the thread that's handling the operation. So then
things work fine.
2) There is something that prevents synchronous suspend (i.e. user activity) so then the
OperationListener gets invoked later by another thread. The completeStep call registers a
rollback handler that will never get called because the op is already done. No harm, no
foul unless the operation rolled back.
3) Same as 2) but the OperationListener gets invoked later by another thread while the
mgmt op is still executing and somehow something goes wrong, since
AbstractOperationContext.Step is not written for concurrent modification.
4) Same as 2) but assertions are enabled and the OperationContext rejects the call with an
AssertionError, impacting the SuspendController functionality.
ServerSuspendHandler tries to do step completion and rollback
handling in a different thread
--------------------------------------------------------------------------------------------
Key: WFCORE-1616
URL:
https://issues.jboss.org/browse/WFCORE-1616
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
ServerSuspendHandler is calling OperationContext.completeStep() and passing in a rollback
handler from a org.jboss.as.server.suspend.OperationListener that may be invoked by a
different thread. The OperationContext is not intended to be invoked from multiple threads
in this way.
3 things can happen with this setup:
1) There is no activity preventing suspend, so the suspend controller immediately calls
back to the OperationListener on the thread that's handling the operation. So then
things work fine.
2) There is something that prevents synchronous suspend (i.e. user activity) so then the
OperationListener gets invoked later by another thread. The completeStep call registers a
rollback handler that will never get called because the op is already done. No harm, no
foul unless the operation rolled back.
3) Same as 2) but the OperationListener gets invoked later by another thread while the
mgmt op is still executing and somehow something goes wrong, since
AbstractOperationContext.Step is not written for concurrent modification.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)