On Fri, Sep 24, 2010 at 2:46 AM, Nikolaos Giannopoulos <nikol...@brightminds.org> wrote: > Joaquin, > > So if you look at the two types of exceptions you have logged the first > is of the following form and the 2nd is similar. > > [16/Sep/2010:09:38:15] info ( 2360): CORE3282: stdout: Caused by: > org.hibernate.exception.JDBCConnectionException: could not execute query > ... > [16/Sep/2010:09:38:15] info ( 2360): CORE3282: stdout: Caused by: > org.postgresql.util.PSQLException: An I/O error occured while sending to > the backend. > ... > [16/Sep/2010:09:38:15] info ( 2360): CORE3282: stdout: Caused by: > java.net.SocketException: Connection reset by peer: socket write error > ... > > What's important is to zero in on the initial "Caused by" in the stack > trace (i.e. the last one) and as you can see it is: > Caused by: java.net.SocketException: Connection reset by peer: socket > write error > > What this is typically caused by is someone closing a web browser > session while the server is processing the request... .
Huh, no. The socket that is closed is the one to the PostgreSQL server, not the one to the browser. There's no application code trying to write the HTTP response in the stack between the entry point in Hibernate and the throw of the exception in the PSQL JDBC driver, hence no opportunity to write on the browser's socket. If it were a "connection closed" message, I'd say that PSQL sets a TTL on its connection like MySQL does, but the "connection reset by peer" looks like a firewall between the application and the DB which has lost track of the open connection, due to it staying idle too long. Or maybe Java hasn't noticed that the connection was closed earlier and is now only getting a reset status. Anyway, to mitigate that, you could set your connection pool to close connections that have stayed idle too long. And actually it seems your c3p0 is at least partially configured to do so with the c3p0.idle_test_period parameter. I don't use it and don't know it, but isn't there another parameter to declare the max idle time which doesn't have a decent default value ? With DBCP (the standard pool used by Tomcat but also usable directly through Hibernate, as c3p0 is here), a typical configuration to do that would be (somewhat matching yours) : maxActive = 20 maxIdle = -1 minIdle = 5 maxWait = 100 minEvictableIdleTimeMillis = 300000 (5 minutes idle before getting closed) timeBetweenEvictionRunsMillis = 30000 (check every 30 seconds for idle connections to close) However, since you're getting connection resets, I'd really set minIdle (or c3p0.min_size) to 0, since keeping 5 connections opened no matter what could keep some opened forever, while the DB closes it on the other end, be it because of a time to live or a time to idle setting. Once your application sees some activity again, it can probably wait for the time to re-establish a connection. Unless it only sees short bursts of intense activity, in which case you might want to change the setting on the DB side. Frank ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
