We had problems with the re-connect feature of SimpleRemoteStatelessSessionProxyFactoryBean: restarting the application server (WebSphere 5.1) hosting the SLSB caused the client proxy to that SLSB to become stale and did not trigger a re-lookup of the Home Interface of the SLSB (aka re-connect). The result was, that the client kept receiving RemoteExceptions even after the application server was up again.
Referring to the source of Spring 1.1.3:
The re-connect decision is made in AbstractRemoteSlsbInvokerInterceptor.invoke() with the help of RmiClientInterceptorUtils.isConnectFailure(): ConnectException, ConnectIOException and NoSuchObjectException (all sub-classes of RemoteException) trigger a re-connect, all other RemoteExceptions don't. In our case, after the restart of the application server, a MarshalException (also a sub-classes of RemoteException) was thrown to the client, which consequently did not trigger a re-connect.
Why be so restrictive on the RemoteExceptions that cause a re-connect? Probably because if a SLSB method throws a RuntimeException (system exception) this is re-thrown as a RemoteException to the client and we don't in general want such a case to result in a re-connect (which would cause the method to be executed again).
(In our case, we simply treated all RemoteExceptions as a sign to attempt a re-connect because our SLSB methods were idempotent.)
The least one could do is to be more complete (in RmiClientInterceptorUtils.isConnectFailure()) in the sub-classes of RemoteException that trigger a re-connect: