[
https://issues.jboss.org/browse/WFCORE-3594?page=com.atlassian.jira.plugi...
]
Brian Stansberry commented on WFCORE-3594:
------------------------------------------
BTW it turns out the reason the offload to an executor mentioned in the description above
even exists was because of WFCORE-3597. Our test clients would get the 'early'
response to the reload op and would then carry on and close the client, which in turn
would signal the server that the channel is closed, which in turn would interrupt
in-flight management ops associated with that channel, i.e. the still in-progress reload.
That would end up interrupting process state listeners preventing their doing their work,
leading to intermittent failures in ProcessStateListenerTestCase. I believe offloading
the listener calls to a separate thread was a workaround to avoid the interruption.
Now the client doesn't get the response until after the listeners have been called.
Reload is racey with regard to reading the process state, which can
cause intermittent test failures
----------------------------------------------------------------------------------------------------
Key: WFCORE-3594
URL:
https://issues.jboss.org/browse/WFCORE-3594
Project: WildFly Core
Issue Type: Bug
Reporter: Stuart Douglas
Assignee: Brian Stansberry
Fix For: 4.0.0.Beta2
This can cause failures as seen at:
https://ci.wildfly.org/viewLog.html?buildId=88799&tab=buildResultsDiv...
The issue is that the reload operation offloads the actual reload operation to an
executor, which means that it is possible to execute :reload operation followed
immediately by reading the 'server-state' attribute and see a state of
'running', even though the server has not reloaded yet.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)