According to me EJBClientInvocationContext does not handle spurious wakeups correctly.
Happened only a couple of times so far.(only seen in automated tests running on Windows 7 on VMware)
Caused by: java.util.concurrent.TimeoutException: No invocation response received in 300000 milliseconds. Waiting since 1392293679695. Now = 1392293679698
at org.jboss.ejb.client.EJBClientInvocationContext$InvocationTimeoutResultProducer.getResult(EJBClientInvocationContext.java:704)
....
in the code of EJBClientInvocationContext ( +/- line 430) :
// If the state is still waiting and the invocation timeout was specified,
// then it indicates that the Object.wait(timeout) returned due to a timeout.
if (state == State.WAITING && invocationTimeout > 0) {
// setup a invocation timeout result producer
this.resultReady(new InvocationTimeoutResultProducer(invocationTimeout, waitStartTime));
break;
}
In the case of a spurious wakeup and a invocationTimeout is specified (300000 in our case) a InvocationTimeoutResultProducer will be produces although there was
no timeout as it was only waiting for 3 ms !!!! ( 1392293679698[now] - 1392293679695(since) = 3 !!!!)
So I think the condition invocationTimeout > 0 is not enough, it should also check for the real waited time.