db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew McIntyre <fuzzylo...@nonintuitive.com>
Subject Re: [VOTE] Re: Help detecting client disconnects for network server
Date Mon, 11 Oct 2004 21:18:46 GMT

On Oct 11, 2004, at 10:43 AM, Kathey Marsden wrote:

> 1) Have keepAlive on by default. It seems important not only for locks
> but for potential network server bloat due to connections not getting
> cleaned up.
> 2) Add a property derby.drda.keepAlive={true|false} (defaults to true 
> as
> described above).  There seems to be a need to be able to turn 
> keepAlive
> off in some cases.

I'd still rather have an internal timing mechanism instead of relying 
on an external mechanism that we cannot discern or set the properties 
of and that the implementation of which is inconsistent across 
platforms. But this is certainly the most expedient way at the moment 
to reap silent client connections, and leaves open the possibility that 
we can have connections that are just silent for a long time, for 
whatever reason, or for some reason, keepalive is set to a lower value 
on the system than is desirable for the particular Derby application. 

> 3) Add property derby.drda.connSoTimeout=<milliseconds> (defaults to 0,
> infinite) to provide the ability to have connections timeout after a
> period of inactivity. The connections will still timeout, even if the
> connection is working fine but will timeout after blocking on a read 
> for
> this length of time.   I am about +.5 on this one.  It would be nice to
> provide the capability, but hesitate to add yet another property.

It seems like this would be nice for tuning purposes, e.g. in cases 
where you expect a large number of client connects and you want each 
connection to be short-lived. Since the default value is essentially 
the same behavior we have today, I don't see a problem with adding the 
property. +1


View raw message