-
Enhancement
-
Resolution: Done
-
Major
-
None
-
None
-
False
-
None
-
False
-
-
Context:
org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not stop container at org.jboss.as.arquillian.container.CommonManagedDeployableContainer.stopInternal(CommonManagedDeployableContainer.java:222) at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.stopInternal(ManagedDeployableContainer.java:160) at org.jboss.as.arquillian.container.CommonDeployableContainer.stop(CommonDeployableContainer.java:154) at org.jboss.arquillian.container.impl.ContainerImpl.stop(ContainerImpl.java:199) .... Caused by: java.io.IOException: java.util.concurrent.CancellationException: JBTHR00004: Operation was cancelled at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:135) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:61) at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:52) at org.jboss.as.arquillian.container.CommonManagedDeployableContainer.stopInternal(CommonManagedDeployableContainer.java:199) ... 148 more Caused by: java.util.concurrent.CancellationException: JBTHR00004: Operation was cancelled at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:251) at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:40) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:133) ... 151 more
This test seems to fail regularly on CI jobs on s390. Appears to be something environmental and timing related.
ANYWAY...
Looking at the server logs it's clear that on the server side the server shutdown proceeded normally and completed in < 600ms. So the 'shutdown' op failing on the client side with a CancellationException doesn't indicate the shutdown didn't actually work.
I believe this is because the server side shutdown is closing the connection to the client before the op response is sent, hence the 'cancellation' seen on the client side.
The server has logic to try and send the response before stopping things when it gets a 'reload' op, but not for 'shutdown'. See ModelControllerClientOperationHandler
if (context == null || !RELOAD_OPERATIONS.contains(operation.get(OP).asString())) { // TODO deal with shutdown as well, // the handlers for which have some // subtleties that need thought ...
ANYWAY...
It seems this CancellationException is a not-uncommon thing in some contexts, so WFARQ can catch and deal with it. CommonManagedDeployableContainer.stopInternal already has logic for dealing with cases where the 'shutdown' op outcome isn't 'success', so equivalent logic can be applied in a 'catch (CancellationException ce)' block.
- is related to
-
WFLY-15822 GroupListenerTestCase fails intermittently
- Resolved
- is triggered by
-
WFLY-18780 Fix s390x test failures
- Resolved