Re: Software Caused Connection Abort (10053) on Client

> 1. Our server was binding a reference to its stub instead of "this" in
> it's Registry.

I don't immediately see why this should matter.  If it's an external
registry, impl-to-stub replacement should happen automatically as
part of the bind remote call anyway.  If it's an in-VM registry obtained
using createRegistry, then impl-to-stub replacement should happen
automatically as part of the return from a lookup remote call.
So what the client sees should be the same in the end.

> 2. The agent registry used a caching mechanism to only lookup the server
> stub once. It then wrapped the cached stubs in a SmartProxy that would
> re-lookup the stub in the server's registry only if an invocation
> handler produced a NoSuchObjectException.

Ah, on the server side, NoSuchObjectException is treated like a
server-side failure, and is subject to the same problem described
in bug 4716483: the NoSuchObjectException will be marshalled back
to the client, but the arguments of the call will not be consumed,
and will be treated incorrectly as bits of a subsequent call.
(I notice that you can only see server-side logging of the
NoSuchObjectException by using the sun.rmi.server.call logger
(or setting java.rmi.server.logCalls), you won't see if by
setting sun.rmi.server.exceptionTrace.)

> For some reason it looks like either one of these alone was ok but
> together they introduced unreliable behavior (oddly just on windows so
> far).

How certain are you of the correlation with how the registry bind
is performed?

> The best way to see it would be to restart the server (but not the
> agent). Then have the agent invoke a call on the server after it had
> restarted. It's cached stub would be invalid, so the first attempt to
> invoke a method on it would cause the SmartProxy to re-lookup the stub
> from the server's registry.

Are you certain the SmartProxy is actually seeing the
NoSuchObjectException?  Because if it does receive it, the client
side should be treating the connection as not reusable, and the
next call should be using a new connection.  The simpler explanation
would be that you have enough argument data that, depending on
scheduling, you can't reliably receive NoSuchObjectException.

- Bob

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff RMI-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

For a list of frequently asked RMI questions please refer to:
http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html

To view past RMI-USERS postings, please see:
http://archives.java.sun.com/archives/rmi-users.html