When connecting from a java client using jacorb to a C++ server that is registered with the TAO ImR (using the PERSISTENT server policy), if that server suddenly fails unexpectedly, further attempts to contact it will result in a TRANSIENT exception:

Exception in thread "Thread-26" org.omg.CORBA.TRANSIENT: Retries exceeded, couldn't reconnect to 127.0.0.1:61463  vmcid: 0x0  minor code: 0  completed: No
    at org.jacorb.orb.iiop.ClientIIOPConnection.connect(ClientIIOPConnection.java:232)
    at org.jacorb.orb.giop.GIOPConnection.sendMessage(GIOPConnection.java:934)
    at org.jacorb.orb.giop.GIOPConnection.sendRequest(GIOPConnection.java:900)
    at org.jacorb.orb.giop.ClientConnection.sendRequest(ClientConnection.java:323)
    at org.jacorb.orb.giop.ClientConnection.sendRequest(ClientConnection.java:304)
    at org.jacorb.orb.Delegate.invoke_internal(Delegate.java:1024)
    at org.jacorb.orb.Delegate.invoke(Delegate.java:939)
    at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:457)

However, the server should be automatically restarted by the ImR when further requests are sent but instead this exception is returned.  Note that to reproduce this bug in practice I've simply been using process explorer to kill the exe, then making the original request to the server which triggers the above TRANSIENT exception.

This could possibly be related to Bug810 (in particular "Problem 3" mentioned in the description), but I really don't know.  I've also noticed in the try_rebind() method of the Delegate class that after a server has been terminated and I make a request to it the 'piorOriginal' is null which from what I understand should be set to the ImR's IOR (It sets it to null in the try_rebind() method, but even after commenting that line out and rebuilding jacorb, it still comes up as null).  I'm not positive, but it seems that when the try_rebind() is called that it is a different Delegate object than was used when the original bind() was done (which doesn't seem right).

There's also the 'useIMR' block of code in the try_rebind() method, which will only work with the jacorb ImR.  This initially seemed like it was the reason I couldn't get automatic rebinding through the TAO ImR (our C++ servers are started with the UseIMR option), but not convinced that's the case.

Some notes: I specified version 2.3.0 which is what we use, but it has a local patch to fix Bug810 (simply adds a loop counter that terminates after so many attempts) and I've tested the issue with version 2.3.1 and had the same issue.  I'm running Windows 7 with jdk 1.6.0_21 (64-bit).