commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz (JIRA)" <>
Subject [jira] [Commented] (DBCP-443) Evictor thread not passing DBCP connectionProperties to Driver.connect()
Date Thu, 30 Jul 2015 17:29:04 GMT


Phil Steitz commented on DBCP-443:

Thanks for the report and work to trace.  This likely affects 2.x as well, assuming there
is not something extra-DBCP/POOL going on.  What is strange is that the properties should
be attached to the connection factory when the pool is initialized and the same factory is
used by both the evictor and the datasource.  I will dig into this some more.  Other eyeballs,
ideas welcome.

> Evictor thread not passing DBCP connectionProperties to Driver.connect()
> ------------------------------------------------------------------------
>                 Key: DBCP-443
>                 URL:
>             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 5.1.31
> 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"
>               connectionProperties="connectTimeout=10000;socketTimeout=20000;useUnicode=true;characterSetResults=utf8;cacheServerConfiguration=true;alwaysSendSetIsolation=false;useLocalSessionState=true;useLocalTransactionState=true;useHostsInPrivileges=false;enableQueryTimeouts=true;maintainTimeStats=false;maxAllowedPacket=-1;"/>
> 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