Re: proposal: setKeepAlive
От | Oliver Jowett |
---|---|
Тема | Re: proposal: setKeepAlive |
Дата | |
Msg-id | 47AE2D07.50904@opencloud.com обсуждение исходный текст |
Ответ на | Re: proposal: setKeepAlive (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: proposal: setKeepAlive
Re: proposal: setKeepAlive |
Список | pgsql-jdbc |
Gregory Stark wrote: > TCP is supposed to work even if the network disappears and then reappears > later, gracefully handling intermittent network failures. The case where you > want to close connections which doesn't respond quickly is when you have hosts > (usually clients, which makes it strange to want this in a database client > driver) which are frequently permanently unplugged or renumbered such as > dialup users. That's why it's important for ftp servers or web servers. People seem to like to put stateful firewalls with low connection activity timeouts between their DB server and client. We get regular traffic on the list from people who see connections get reset on their first use after a long idle period. Presumably TCP keepalive would help in some of these cases. Also, usually DB connections are local and you don't really want to plaster over the fact that the other end has gone MIA. Between default TCP retransmission times and default TCP keepalive settings and the lack of a uniform setQueryTimeout() within the driver, it's actually really hard to work out promptly that the DB server is dead which is a royal pain if you are trying to do failover between servers. 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. > "Kris Jurka" <books@ejurka.com> writes: > >> > Java does not support a configurable keepalive interval, it's simply an on/off >> > flag. > > Uhm, well that kind of sucks, though to be honest I suspect most people who > override the OS default set it to inappropriately short intervals anyways. The lack of support in Java is why when I did the server-side work to support configurable TCP keepalive I didn't do the Java side too - the default OS timeouts are way too large for the case I cared about. Also, the Java side doesn't sit around waiting on read, so it won't actually notice the connection is dead until the next time it tries to use it anyway, at which point you might as well just poll the server with a dummy query every X seconds. -O
В списке pgsql-jdbc по дате отправления: