You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Marco Boniardi (JIRA)" <ji...@apache.org> on 2008/04/19 19:58:22 UTC
[jira] Created: (DBCP-266) connection pool is not being kept alive
by dbcp
connection pool is not being kept alive by dbcp
-----------------------------------------------
Key: DBCP-266
URL: https://issues.apache.org/jira/browse/DBCP-266
Project: Commons Dbcp
Issue Type: Bug
Environment: Apache Tomcat 6.0.16
Jdk 1.6.0_05-b13 Sun Microsystems Inc.
Linux 2.6.18-53.1.4.el5 amd64
mysql-connector-java-5.0.8-bin.jar
Reporter: Marco Boniardi
In our production environment, randomly the connection pool in Tomcat 6.0.16 collapses, no errors, just hunged.
You can not retrive it from context with a lookup, we can not have connections.
All requests hunged. We think it's closely related to db idle connection management, with idle connection closed server side due to timeout while the connection pool does not realize this.
After a couple of week of investigation, we discovered this:
we see validation query running, but very often the time between 2 validation query runs is not timeBetweenEvictionRunsMillis.
It's double, we wrote 40 seconds, it runs every 80 seconds.
For some reason, in some machine of our cluster (older tomcat restart?) we see validation query running every 160 seconds for all connection, 4 times timeBetweenEvictionRunsMillis, and it's stable, always 160 sec., even if we don't know if tomorrow it goes to 320sec. or it stays to 160. In our idea there is something wrong with the Timer that manage to run query validation for idle connection. Problably timeBetweenEvictionRunsMillis grows over server timeout period causing connections pool collape.
Till 3 weeks ago we had Tom 5.0.x and everything was perfect.
After we moved to Tomcat 6.0.16 we have to restart 1-2 servers /day in a 10 serves cluster due to hunged connection pool.
The problem is not related to traffic because it happends night time too.
I hope this can help to figure out the problem.
Regards
Marco Boniardi
<Resource
name="jdbc/bestprices"
type="javax.sql.DataSource"
initialSize="5"
maxActive="15"
maxIdle="15"
minIdle="5"
maxWait="5000"
testOnBorrow="false"
testWhileIdle="true"
timeBetweenEvictionRunsMillis="40000"
minEvictableIdleTimeMillis="240000"
validationQuery="SELECT 1"
username="bestprices_user"
password="xxxxxxxx"
driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://vgdb05:3306/bestprices?zeroDateTime-Behavior=convertToNull"
/>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DBCP-266) connection pool is not being kept alive
by dbcp
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Steitz closed DBCP-266.
----------------------------
> connection pool is not being kept alive by dbcp
> -----------------------------------------------
>
> Key: DBCP-266
> URL: https://issues.apache.org/jira/browse/DBCP-266
> Project: Commons Dbcp
> Issue Type: Bug
> Environment: Apache Tomcat 6.0.16
> Jdk 1.6.0_05-b13 Sun Microsystems Inc.
> Linux 2.6.18-53.1.4.el5 amd64
> mysql-connector-java-5.0.8-bin.jar
> Reporter: Marco Boniardi
>
> In our production environment, randomly the connection pool in Tomcat 6.0.16 collapses, no errors, just hunged.
> You can not retrive it from context with a lookup, we can not have connections.
> All requests hunged. We think it's closely related to db idle connection management, with idle connection closed server side due to timeout while the connection pool does not realize this.
> After a couple of week of investigation, we discovered this:
> we see validation query running, but very often the time between 2 validation query runs is not timeBetweenEvictionRunsMillis.
> It's double, we wrote 40 seconds, it runs every 80 seconds.
> For some reason, in some machine of our cluster (older tomcat restart?) we see validation query running every 160 seconds for all connection, 4 times timeBetweenEvictionRunsMillis, and it's stable, always 160 sec., even if we don't know if tomorrow it goes to 320sec. or it stays to 160. In our idea there is something wrong with the Timer that manage to run query validation for idle connection. Problably timeBetweenEvictionRunsMillis grows over server timeout period causing connections pool collape.
> Till 3 weeks ago we had Tom 5.0.x and everything was perfect.
> After we moved to Tomcat 6.0.16 we have to restart 1-2 servers /day in a 10 serves cluster due to hunged connection pool.
> The problem is not related to traffic because it happends night time too.
> I hope this can help to figure out the problem.
> Regards
> Marco Boniardi
> <Resource
> name="jdbc/bestprices"
> type="javax.sql.DataSource"
> initialSize="5"
> maxActive="15"
> maxIdle="15"
> minIdle="5"
> maxWait="5000"
> testOnBorrow="false"
> testWhileIdle="true"
> timeBetweenEvictionRunsMillis="40000"
> minEvictableIdleTimeMillis="240000"
> validationQuery="SELECT 1"
> username="bestprices_user"
> password="xxxxxxxx"
> driverClassName="com.mysql.jdbc.Driver"
> url="jdbc:mysql://vgdb05:3306/bestprices?zeroDateTime-Behavior=convertToNull"
> />
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DBCP-266) connection pool is not being kept alive
by dbcp
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Steitz resolved DBCP-266.
------------------------------
Resolution: Incomplete
Please reopen with relevant threads from a full thread dump showing the deadlock if this can be confirmed.
> connection pool is not being kept alive by dbcp
> -----------------------------------------------
>
> Key: DBCP-266
> URL: https://issues.apache.org/jira/browse/DBCP-266
> Project: Commons Dbcp
> Issue Type: Bug
> Environment: Apache Tomcat 6.0.16
> Jdk 1.6.0_05-b13 Sun Microsystems Inc.
> Linux 2.6.18-53.1.4.el5 amd64
> mysql-connector-java-5.0.8-bin.jar
> Reporter: Marco Boniardi
>
> In our production environment, randomly the connection pool in Tomcat 6.0.16 collapses, no errors, just hunged.
> You can not retrive it from context with a lookup, we can not have connections.
> All requests hunged. We think it's closely related to db idle connection management, with idle connection closed server side due to timeout while the connection pool does not realize this.
> After a couple of week of investigation, we discovered this:
> we see validation query running, but very often the time between 2 validation query runs is not timeBetweenEvictionRunsMillis.
> It's double, we wrote 40 seconds, it runs every 80 seconds.
> For some reason, in some machine of our cluster (older tomcat restart?) we see validation query running every 160 seconds for all connection, 4 times timeBetweenEvictionRunsMillis, and it's stable, always 160 sec., even if we don't know if tomorrow it goes to 320sec. or it stays to 160. In our idea there is something wrong with the Timer that manage to run query validation for idle connection. Problably timeBetweenEvictionRunsMillis grows over server timeout period causing connections pool collape.
> Till 3 weeks ago we had Tom 5.0.x and everything was perfect.
> After we moved to Tomcat 6.0.16 we have to restart 1-2 servers /day in a 10 serves cluster due to hunged connection pool.
> The problem is not related to traffic because it happends night time too.
> I hope this can help to figure out the problem.
> Regards
> Marco Boniardi
> <Resource
> name="jdbc/bestprices"
> type="javax.sql.DataSource"
> initialSize="5"
> maxActive="15"
> maxIdle="15"
> minIdle="5"
> maxWait="5000"
> testOnBorrow="false"
> testWhileIdle="true"
> timeBetweenEvictionRunsMillis="40000"
> minEvictableIdleTimeMillis="240000"
> validationQuery="SELECT 1"
> username="bestprices_user"
> password="xxxxxxxx"
> driverClassName="com.mysql.jdbc.Driver"
> url="jdbc:mysql://vgdb05:3306/bestprices?zeroDateTime-Behavior=convertToNull"
> />
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.