Re: Software Caused Connection Abort (10053) on Client

Oh, additionally, if I just fix #1, I still get a NoSuchObjectException
from serviceCall on the server (after a server restart), but it does not
cause the connection to be in an unknown state.

-----Original Message-----
From: Robert DiFalco [mailto:[email protected]] 
Sent: Tuesday, November 29, 2005 9:41 AM
To: [email protected]
Subject: Re: Software Caused Connection Abort (10053) on Client

Ok, lets see how this sits with you. I think the problem is a
combination of things. 

1. Our server was binding a reference to its stub instead of "this" in
it's Registry.
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.

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). 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. But unfortunately at that point the
connection was already hosed. If I fix #1 or change #2 so it always gets
the stub from the registry (no caching) or fix both, the errant behavior
goes away. Plausable?

R.

-----Original Message-----
From: Bob Scheifler [mailto:[email protected]]
Sent: Tuesday, November 29, 2005 6:58 AM
To: Robert DiFalco
Cc: [email protected]
Subject: Re: Software Caused Connection Abort (10053) on Client

> In the case of 4716483 wouldn't I have seen something on the client 
> besides just the 10053 socket error?

Not if the arguments of the call are sufficiently large.  Read the 2nd
and 3rd paragraphs of the bug report again.  The server may have
marshalled the exception, but it will immediately process what it thinks
is the next call, see the bad transport op, and close the connection.
The client could still be marshalling its arguments, and not yet gotten
around to reading the exception that was marshalled.

- 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

===========================================================================
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