As an important performance optimization, org.jnp.interfaces.NamingContext statically caches a WeakReference to the "proxy" to the server-side Naming service. In most cases this is either an RMI stub (non-HA naming service) or a proxy based on an HARMIClient (for HA-JNDI). Either way, the cached object uses RMI to communicate with the server.

This object becomes invalid if the server (non-HA case) or cluster (HA case) it was associated with is restarted. The object in the restarted server-side RMI runtime will no longer match the client-side RMI stub, and an invocation over the stub will result in a java.rmi.NoSuchObjectException on the client. NamingContext's caching of the RMI greatly increases the odds of this occuring. If this occurs, the cache will be flushed and the next call will acquire a fresh stub from the server, but the client will get an exception on the first call.

Proposed solution is discussed on forum thread.