db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samuel Andrew McIntyre <fuzzylo...@nonintuitive.com>
Subject Re: Help detecting client disconnects for network server
Date Mon, 11 Oct 2004 06:20:33 GMT
On Oct 10, 2004, at 4:33 AM, Jan Hlavatý wrote:

> This is simply not true. SO_KEEPALIVE works, even for blocking in 
> reads.
> I have tested it.

Agreed. After writing the previous comments, I decided I should just go 
see how it works in practice. :-) After the keepalive timeout, a 
SocketException is thrown. (Exception in thread "main" 
java.net.SocketException: Operation timed out at 
java.net.SocketInputStream.socketRead0(Native Method))

I also tried the following (all on Mac OS X):

setting .setSoTimeout(0) along with keepalive, and the same behavior is 
observed. It would then appear that without a way to turn off 
keepalive, there's no way to specify that we want to keep the socket 
open indefinitely.

Also, in the case where timeout interval > keepalive interval, the 
keepalive timer closes the socket before the timeout value is reached. 
While this may not be a problem for some platforms, the default value 
for net.inet.tcp.keepidle on the Mac is 144s and the interval for 
probing is only 1.5 secs, meaning that with keepalive turned on, 
timeout values greater than 3 minutes would have no effect and 
keepalive would always close the socket at between 2 and 3 minutes. It 
would seem that Mac OS X is violating RFC1122, but still, that's what 
the value currently is on the three systems at my disposal.

So, I'm still not sure that I like having keepalive set by default 
without a way to turn it off. Anyway, I haven't been able to test this 
on other operating systems yet to see if the same behavior is true for 
setSoTimeout/setKeepAlive, but I'm curious if there's any difference 
between Linux, Solaris and Windows, so I'll get back to you on that.


View raw message