[
https://issues.apache.org/jira/browse/DBCP-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13222960#comment-13222960
]
Shuo QIU commented on DBCP-377:
-------------------------------
(I am )The broken connection is either closed by F5 or the middleware, for that
when dbcp connect directly to middleware rather than through F5, some
connections (less than 1 per hour) kept idle longer than 1 hour are closed by
middleware (which is showed in middleware's log).
I suspect:
1, as Mark said: app could obtain a connection from the pool but never use it
2, is it possible that, dbcp makes GeneralObjectPool's lock granularity finer
which cause concurrent problem. So that evictor miss some connections for check.
> Dbcp Idle Check Mechanism Doesn't Work
> --------------------------------------
>
> Key: DBCP-377
> URL: https://issues.apache.org/jira/browse/DBCP-377
> 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}
> java.net.SocketException
> MESSAGE: Broken pipe
> STACKTRACE:
> java.net.SocketException: Broken pipe
> at java.net.SocketOutputStream.socketWrite0(Native Method)
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
> at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:2637)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1554)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1665)
> at com.mysql.jdbc.Connection.execSQL(Connection.java:3176)
> at
> com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1153)
> at
> com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:794)
> ....
> at
> org.apache.commons.dbcp.DelegatingPreparedStatement.execute(DelegatingPreparedStatement.java:172)
> at
> org.apache.commons.dbcp.DelegatingPreparedStatement.execute(DelegatingPreparedStatement.java:172)
> {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 Mechanism？
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
