commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Thomas (Commented) (JIRA)" <>
Subject [jira] [Commented] (DBCP-377) Dbcp Idle Check Mechanism Doesn't Work
Date Mon, 05 Mar 2012 22:01:57 GMT


Mark Thomas commented on DBCP-377:

I'm not aware of any known issues with idle object eviction.

It shouldn't be the app holding on to an idle connection too long before returning it since
the removeAbandoned* settings will handle that after 5 minutes.

I assume that you are 100% certain that the middleware layer is dropping the connections after
1 hour.

Can you provide some idea of the frequency this occurs? E.g x failures per hour and y connections
borrowed per second. I'm trying to understand how rare the issue is.

Some things to check:
1. What version of commons-pool are you using and if it isn't the latest does upgrading fix
the issue?
2. numTestsPerEvictionRun=32 seems too high if maxIdle=20
3. Is it possible that the app could obtain a connection from the pool but never use it? That
would reset DBCP's idle timer but not the middleware layer's.
> Dbcp Idle Check Mechanism Doesn't Work
> --------------------------------------
>                 Key: DBCP-377
>                 URL:
>             Project: Commons Dbcp
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: Linux mysql 5.1.4
>            Reporter: yixin he
>            Priority: Critical
> Using :commons-dbcp-1.4.jar version
> we use a distributed data access layer for Database Sharding with mysql
> our web servers use mysql jdbc driver 1.5.4 to connect to this middleware layer with
F5 between them for load balance.
> the middleware layer will discard db links that idle for longger than 1 hour,and our
dbcp configures to close links that idle for 
> longger than 30 minutes.
> here we occurred exceptions as follows:
> {code}
> MESSAGE: Broken pipe
> Broken pipe
>         at Method)
>         at
>         at
>         at
>         at
>         at com.mysql.jdbc.MysqlIO.send(
>         at com.mysql.jdbc.MysqlIO.sendCommand(
>         at com.mysql.jdbc.MysqlIO.sqlQueryDirect(
>         at com.mysql.jdbc.Connection.execSQL(
>         at com.mysql.jdbc.PreparedStatement.executeInternal(
>         at com.mysql.jdbc.PreparedStatement.execute(
>         ....
>         at org.apache.commons.dbcp.DelegatingPreparedStatement.execute(
>         at org.apache.commons.dbcp.DelegatingPreparedStatement.execute(
> {code}
> it seems that there are times when the links get from pool they have already been broken,we
know that they are forcely closed by the middleware layer、but as dbcp idle check more frequently
than the middleware layer(30m to 60m). How can this happen as the idle links
> should have been closed by dbcp first. Are there any problems for the dbcp idle check
> our dbcp configurations are as follows
> {code}
>     <property name="maxActive"><value>20</value></property>
>     <property name="initialSize"><value>1</value></property>
>     <property name="maxWait"><value>60000</value></property>
>     <property name="maxIdle"><value>20</value></property>
>     <property name="minIdle"><value>5</value></property>
>     <property name="removeAbandoned"><value>true</value></property>
>     <property name="removeAbandonedTimeout"><value>180</value></property>
>     <property name="connectionProperties"><value>clientEncoding=GBK</value></property>
>     <property name="timeBetweenEvictionRunsMillis"><value>60000</value></property>
>     <property name="minEvictableIdleTimeMillis"><value>1800000</value></property>
>     <property name="testWhileIdle"><value>true</value></property>
>     <property name="testOnBorrow"><value>false</value></property>
>     <property name="testOnReturn"><value>false</value></property>
>     <property name="validationQuery"><value>SELECT @@SQL_MODE</value></property>
>     <property name="numTestsPerEvictionRun"><value>32</value></property>
> {code}

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message