[ https://issues.jboss.org/browse/WFLY-3532?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on WFLY-3532: ------------------------------------------- I'll try and explain a little better: When we make an invocation, we start out with an EJBClientInvocationContext representing the invocation client and the invocation parameters. We then choose an EJBReceiver which can handle the invocation and create an EJBReceiverInvocationContext to represent it. The EJBReceiverInvocationContext refers to the EJBReceiver and also Channel used. When we successfully send out an invocation on a channel, we store the fact that we need to wai for a response, and store this fact in a map (ChannelAssociation.waitingMethodInvocations) specifying the invocationId and the EJBReceiverInvocationContext. If the response does not return, or returns with an EJBUnavailableException, we retry the invocation, ultimately using a new EJBReceiverInvocationContext (and so a new Channel). What was causing the exception was that, before retrying, we were not removing the the stored fact that we were waiting on an old EJBReceiverInvocationContext and Channel. When that Channel closed as a result of the server shutting down, it triggered the exception that we were seeing, despite the fact that a new EJBReceiver was being chosen and the retry of the invocation was failing over correctly. -- This message was sent by Atlassian JIRA (v6.3.11#6341)