wildfly/wildfly — pull request #4645 by jaikiran (2013-06-14 14:34:23+00:00)
Title: WFLY-1532 Fix intermittent failure in RemoteCallWhileShuttingDownTestCase

The commit here fixes the intermittent failure in RemoteCallWhileShuttingDownTestCase.testServerShutdownRemoteCall which is reported here https://issues.jboss.org/browse/WFLY-1532.

The details of the issue have been added to the JIRA but here's the summary:

That testServerShutdownRemoteCall does the following:

1) Has a @Singleton bean A. The bean has the usual business methods and a @PreDestroy method which waits on a latch in the @PreDestroy.
2) The latch on which the singleton bean A waits on is countDown() in another different singleton bean B, which is injected in A.
3) The test does some business method invocations and then (intentionally) triggers a server shutdown.
4) The shutdown starts the service stop for various services and at the same time waits for the latch to countdown so that the bean A can be undeployed
5) After a while (with a Thread.sleep) the test invokes on the bean B to trigger a latch countdown() so that the shutdown on the server can complete.

#5 is where the trouble lies. Even though the method on bean B, which counts down the latch is marked @Asynchronous, the EJB client API still "waits" at least for a moment for the response from the server, since the EJB client API doesn't know that the method is @Asynchronous. The asynchronous nature of that method is conveyed as a separate EJB client protocol message, by the server to the EJB client API. So there's a period of time where the EJB client API waits for a response from the server, for that invocation request. Now during this short period of time when the invocation request has been sent by the EJB client and when it's waiting for the response, it can so happen that the latch countdown() happens on the server side and the bean is undeployed and the rest of the shutdown proceeds which ultimately closely the remoting connection/channel on which the EJB communication was happening. This close results in the waiting EJB client to fail with an IOException since it no longer will be able to receive a response from the server.

There's a fix to this issue where the EJBClient.asynchronous(proxy) API can be used so that the latch countdown remote invocation via the EJB client API is really asynchronous and the client doesn't wait for any period of time. @see http://docs.jboss.org/ejbclient/1.0.5.Final/org/jboss/ejb/client/EJBClient.html#asynchronous%28T%29 for more details.