Skip site navigation (1) Skip section navigation (2)

Re: JDBC keep alive issue

From: Craig James <cjames(at)emolecules(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Haifeng Liu <liuhaifeng(at)live(dot)com>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: JDBC keep alive issue
Date: 2012-08-11 11:26:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
On Fri, Aug 10, 2012 at 7:19 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Haifeng Liu <liuhaifeng(at)live(dot)com> writes:
> > I have a program running like a daemon, which analyze data and write to
> postgresql 9.1 on centos 5.8. There is only one connection between my
> program and the postgresql database, and I hope the connection may keep
> alive all the time. But I failed, the connection will be reset after idle
> for about 2 hours.
> > jdbc driver: 9.1-901, connection url has parameter tcpKeepAlive=true;
> > postgresql:9.1, keep alive related settings use default
> values(commented);
> > centos 5.8 64bit, net.ipv4.tcp_keepalive_intvl = 75, probes = 9, time =
> 7200.
> IIRC, time = 7200 (seconds) means to start sending keepalive packets
> after 2 hours of idle time.  So if you have something in the way that is
> dropping the connection after 2 hours, these settings will not activate
> keepalive soon enough to save it.  I'd try setting that to 3600.

I use a much shorter time (300).  Why not?  The keepalive pings are a
trivial amount of data.  I've found over the years that router NAT tables
are a big offender (probably doesn't apply in this case) ... some drop your
internal-to-external IP address mapping after as little as five minutes.


> > There is no firewall or any other device which behaves force idle
> connection cleanup.
> Seems pretty darn unlikely given these symptoms.  Look harder...
> maybe something you thought was just a bridge has got routing behavior.
> BTW, in the real world connections drop for all sorts of reasons, and
> kernel keepalive configurations can't prevent them all.  You might be
> better advised to build some reconnect-after-connection-loss logic into
> your application, rather than spending time on making this work.
>                         regards, tom lane
> -
> Sent via pgsql-admin mailing list (pgsql-admin(at)postgresql(dot)org)
> To make changes to your subscription:

In response to

pgsql-admin by date

Next:From: Richard HarperDate: 2012-08-12 02:26:52
Subject: server not starting
Previous:From: Haifeng LiuDate: 2012-08-10 06:56:02
Subject: JDBC keep alive issue

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group