Re: proposal: setKeepAlive

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Toru SHIMOGAKI <shimogaki(dot)toru(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: proposal: setKeepAlive
Date: 2008-02-09 23:27:25
Message-ID: 47AE36DD.9050102@opencloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Gregory Stark wrote:

> The local case is precisely where you wouldn't want to use keep-alives. When
> the server does come back up you'll get RSET packets and the connections will
> die.

This does assume that the server is not down because it's caught fire..

>> Keepalive helps a little but it's certainly not perfect. I ended up doing
>> all the dead server detection at a higher level in the end.
>
> I think you're doing exactly what you have to do. You certainly don't want to
> predicate failover on simple network reachability. You want to base it on the
> application actually functioning. Network reachability is both too sensitive
> (keep-alive packets could be dropped due to congestion) and not sensitive
> enough (if the application crashes the host may still be reachable).

For the environment I'm running in, network congestion sufficient to
drop multiple keepalive packets is equivalent to server failure anyway.

Agreed that you want application-level tests anyway, it's just that if
there are network problems I would prefer to hear about them sooner
rather than later - it seems a little silly to have the information
available at the TCP level, but ignore it. You have to tune app-level
timeouts to take account of the normal response time of the app, which
might be quite different to the normal response time of the network.

-O

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Gregory Stark 2008-02-10 01:04:00 Re: proposal: setKeepAlive
Previous Message Gregory Stark 2008-02-09 23:18:23 Re: proposal: setKeepAlive