Re: proposal: setKeepAlive
От | Oliver Jowett |
---|---|
Тема | Re: proposal: setKeepAlive |
Дата | |
Msg-id | 47AE36DD.9050102@opencloud.com обсуждение исходный текст |
Ответ на | Re: proposal: setKeepAlive (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: proposal: setKeepAlive
|
Список | 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
В списке pgsql-jdbc по дате отправления: