[ https://issues.jboss.org/browse/WFLY-3532?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on WFLY-3532: ------------------------------------------- This test case is still failing, and in various failure modes, as before; however, in the interim, the mechanism for shutting down the server has changed. Wildfly now incorporates the SuspendController / RequestController / ControlPoint / EJBSuspendInterceptor for managing clean shutdown, whereas previous implemetations made uee of the ShutdownInterceptorFactory for shutting down EJB services in a manageable way. It used to the the case that this test only failed on stop/start of the server. It now fails on undeploy / deploy as well as stop / start. In the case of undeploy, the issue has been isolated and a description appears here: :https://issues.jboss.org/browse/WFLY-4234 In the case of stop / start, there are a couple of issues: - the test case framework uses the clean shutdown mechanism but does not specify a timeout value to give running invocations, which get through before shutdown starts, a chance to finish - if the timeout is adjusted so that either an invocation will get past the interceptor and have a chance to finish or an invocation will not get past the interceptor and return an EJBUnavailableException, then we still get exactly the type of exception as described above. The problem here is that if the EJBInvocationHandler has to retry an invocation on another node, due to an EJBUnavailableException, it does not correctly de-register the original invocation attempt from waiting for results coming off the original Channel; then when the channel does get closed (by the shutting down server), we get the exception described above. The fix here is, before retrying the request, make sure we de-enroll the invocation for waiting for results -- This message was sent by Atlassian JIRA (v6.3.11#6341)