I haven't had the time to duplicate it yet, but this isn't covered by my tests
yet.

Excerpt from one of coryan@cs.wustl.edu emails:

Well, it is always going to be problematic to use oneways with
the IR because the client will not wait for the LOCATION_FORWARD
reply, hence it will never know where is the server running and where
to issue new requests.

The way around this problem is to issue a _non_existent()
request (or another twoway call) to check if the object is there,
hopefully not on every call, just when the server is down (say because
a oneway returned TRANSIENT).
I don't think this should be done by the ORB but rather by the
application, which knows what is the right thing to do and when does
this policy apply.

Another solution is to implement reliable oneways as specified
in CORBA Messaging. In this case the client do wait for a reply from
the server, so there is opportunity to send back a LOCATION_FORWARD
message.  Notice that you don't wait until the request completes, just
until it starts (or even before that) so the client does get some
level of asynchrony.

Waiting for reliable one-ways (bug 256)

Bug 303 is another way to get this to work.

Reliable Oneways fixes this.  But before this bug can be closed, it has to be
tested and verified.