Re: Connection reset

>> It appears that the client was in the middle of unmarshalling a
>> HashMap contained in the return value of a "getDataSet" invocation
>> when the exception occurred.
>
> I got that far in my understanding ... by the way, this HashMap
> could be quite large, does that make a difference?

In theory it shouldn't.

>> As the client was trying to read from the connection, if the server
>> closed its socket because of this timeout, the client should get an
>> EOFException, not a connection reset indication.
>>
>> The two hour delay and the connection reset failure might suggest
>> that the TCP keepalive mechanism triggered the failure. But that
>> would seem to indicate that TCP segments between the client and
>> server machines were getting dropped at some point.  Does other
>> communication between them seem to work throughout this period?
>
> Hmm, interesting - since it's late at night I would have to consult
> with our network admins to see if they had noticed any connection
> problems.
>
>> How reproducible is this failure-- always, occasionally, etc.?
>
> It's occasionally reproducible (and seems to go away when I enable
> RMI logging, grrr...)
>
>> Have you gotten thread dumps from the client and server VMs during
>> this two hour period?  "netstat" output on the client and server
>> machines during this period?
>
> No, but I'll try next time I observe the problem.
>
> We do have upstream retry procedures in place, but obviously they
> are not triggered by a simple client freeze.  What I was trying to
> do with the sun.rmi.transport.tcp.readTimeout property was provoke
> this crash earlier, so that we don't waste 2 hours of machine
> time. Is there another property I should be playing with?

It seems that you want the client-side invocation to fail if it
doesn't hear anything from the server for too long (like in the middle
of unmarshalling the result).  Since 1.4 you can control the
client-side socket read timeout with the following system property[*]:

        sun.rmi.transport.tcp.responseTimeout

with the caveat that this socket read timeout applies equally when
waiting for the beginning of the result, without regard to the
apparent liveness of the server, and therefore it imposes an upper
bound on the duration of any successful remote invocation, even
without server or communication failure.

A client-side socket read timeout can also be imposed with a custom
RMIClientSocketFactory, which allows for finer granularity than
imposing the timeout on all outbound invocations from the VM.  (A
socket read timeout set by a socket factory overrides the system
property setting for that socket.)

There is further discussion of client-side timeouts in the face of
disconnected/unresponsive servers in this post (see case [4] and [2]):

http://archives.java.sun.com/cgi-bin/wa?A2=ind0212&L=rmi-users&P=731

-- Peter

[*] The system property's value is interpreted as an int in
milliseconds as would be passed to Socket.setSoTimeout.  This and
other implementation-specific system properties are documented here:

http://java.sun.com/javase/6/docs/guide/rmi/sunrmiproperties.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