Checked in the unit test I discussed on http://www.jboss.com/index.html?module=bb&op=viewtopic&t=114200 . It's org.jboss.test.naming.test.NamingRestartUnitTestCase. (I was able to track down the thing I was concerned about with deploying a 2nd NamingService and made sure the test didn't cause a problem.) The problem with HA-JNDI is as you described, Ben -- when HA-JNDI is stopped, the server-side Remote is unexported. The client side NamingContext has a cached refer to the stub to that Remote; invoking on that fails. I was able to determine why the test doesn't fail with regular JNDI: 1) For regular JNDI, the server-side Remote object is an instance of NamingServer. That instance is cached in a static field NamingContext.localServer. Thus the server-side object actually survives a restart of the NamingService. 2) NamingService doesn't actually unexport that NamingServer as part of it's stop() processing. From org.jnp.server.Main.stop(): | if( isStubExported == true ) | UnicastRemoteObject.unexportObject(theServer.getNamingInstance(), false); | Field "isStubExported" is never set to "true", so the unexportObject call never happens. Effect is a remote NamingContext still has a valid stub after a restart of the NamingService. If the test actually restarted the server rather than just bouncing a NamingService, it wouldn't work. This is what happens with Ben's manual test above. When I modified the test NamingService so it no longer used the static NamingServer in 1) above, the test fails. Bottom line with all this is we understand the failure mode. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4074194#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...