commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Justin Cranford (JIRA)" <>
Subject [jira] [Created] (DBCP-443) Evictor thread not passing DBCP connectionProperties to Driver.connect()
Date Thu, 30 Jul 2015 14:20:04 GMT
Justin Cranford created DBCP-443:

             Summary: Evictor thread not passing DBCP connectionProperties to Driver.connect()
                 Key: DBCP-443
             Project: Commons Dbcp
          Issue Type: Bug
    Affects Versions: 1.3
         Environment: Tomcat 5.5.31 (bundles DBCP 1.3.0 and Pool 1.5.4)
MySQL Connector/J 5.1.31
MySQL 5.1
            Reporter: Justin Cranford

DBCP 1.3.0 is passing connectionProperties to Driver.connect() when called during borrow,
but not when called by the evictor thread. This is a problem when using DBCP with Connector/J
because that MySQL JDBC driver defaults to connectTimeout=0 (indefinite hang). I am setting
connectTimeout=10000 in my DBCP <Resource> connectionProperties to explicitly avoid
this issue, but DBCP is not always using it in Driver.connect() calls.

I did not see this issue in DBCP change log (
so I am reporting it. I am wondering if this also affects DBCP 1.4/2.x for Java 6/7 respectively,
but I don't have an environment to test that.

Here is the stack being used:

        Tomcat 5.5.31 ===> DBCP 1.3.0 (w/ Pool 1.5.4) ===> HA-JDBC 2.0.15 ===> Connector/J

For background, HA-JDBC is a JDBC proxy connection. It does two-phase to two underlying Connector/J
databases defined in a separate config file. However, the issue has nothing to do with HA-JDBC.

The issue is right at the DBCP entry point into Driver.connect(). In my case, that Driver.connect()
call is into HA-JDBC, and it passes any connection properties down to each Connector/J Driver.connect()

I put a debug on the first line of HA-JDBC's Driver.connect() to confirm this issue. I logged
a stack trace with the value of connectTimeout passed in from DBCP. For DBCP borrow stack
traces, I see connectTimeout=10000. For DBCP evictor stack traces, I see connectTimeot=null.
For example:

        java.lang.Exception: Driver.connect url=jdbc:ha-jdbc:cspm_mysql connectTimeout=null
                at net.sf.hajdbc.sql.Driver.connect(
                at org.apache.tomcat.dbcp.dbcp.DriverConnectionFactory.createConnection(
                at org.apache.tomcat.dbcp.dbcp.PoolableConnectionFactory.makeObject(
                at org.apache.tomcat.dbcp.pool.impl.GenericObjectPool.addObject(
                at org.apache.tomcat.dbcp.pool.impl.GenericObjectPool.ensureMinIdle(
                at org.apache.tomcat.dbcp.pool.impl.GenericObjectPool.access$700(
                at org.apache.tomcat.dbcp.pool.impl.GenericObjectPool$
                at java.util.TimerThread.mainLoop(Unknown Source)
                at Source)

If I am defining DBCP connectionProperties, I would expect DBCP to pass those properties to
all calls of Driver.connect(). I see a Properties object is passed in the evictor thread,
but it does not seem to be initialized properly. I am not sure how to trace that back to BasicDataSource,

Here is my DBCP <Resource>. You can see my connectionProperties for HA-JDBC includes

            <Resource name="jdbc/mydb" auth="Container" type="javax.sql.DataSource"
              maxActive="100" maxIdle="25" minIdle="5"
              removeAbandoned="true" removeAbandonedTimeout="28800" logAbandoned="true"
              validationQueryTimeout="15" validationQuery="/* ping */ SELECT 1 FOR UPDATE"
              testOnBorrow="true" testOnReturn="false" maxWait="15000"
              testWhileIdle="false" timeBetweenEvictionRunsMillis="900000" numTestsPerEvictionRun="10"
              username="mydbpublic" password="mydbpwd"
              driverClassName="net.sf.hajdbc.sql.Driver" url="jdbc:ha-jdbc:mysql"

Another consequence of this issue is Commons Pool 1.5.4 uses a TimerTask for the evictor thread.
TimerTask does not wait for previous iterations to complete. If the evictor timer runs frequenctly,
this issue could accumulate socket and file descriptor resources for hung Connector/J connections.
Maybe that is not a problem for DBCP -> Connector/J setups, but it is for DBCP -> HA-JDBC
-> Connector/J stacks where HA-JDBC attempts to connect to both but only needs one of the
underlying databases to connect while the other hangs.

This message was sent by Atlassian JIRA

View raw message