If all cluster targets have been exhausted in an EJB call, the org.jboss.proxy.ejb.RetryInterceptor will attempt to restore the InvocationContext invoker (and thus get a fresh set of targets) by doing a JNDI lookupof the transport invoker. It will go into a loop and keep attempting the lookup until it succeeds.

This looping behavior is useful in that it allows, for example, a call to eventually succeed even though a complete cluster restart is in progress when the call is first attempted. However, in many use cases, a potentially endless loop is unacceptable. As a result, the RetryInterceptor is not part of the default client-side interceptor stack for a clustered EJB.

A version of the RetryInterceptor that only attempts a single retry would be useful. This SingleRetryInterceptor would allow a call to succeed even though the initial list of targets is invalid, as long as there is a new transport invoker available in JNDI. This would be useful, for example, in the case of a cached EJB home, where a cluster restart has occurred while it was cached. As long as at least one cluster node is available when a new attempt to use the cached home is made, the call will succeed. See the forum discussion thread for more possible use cases.

This will be implemented by adding a maxRetries field to RetryInterceptor, with a default value of -1 meaning loop indefinitely. A protected constructor that takes a maxRetries arg will be added as well. The SingleRetryInterceptor will then be a trivial subclass that passes "1" to the superclass constructor. This approach will make it trivial for users who want a custom version (e.g. 20 retries max) to make one.