[jira] [Commented] (DBCP-443) Evictor thread not passing DBCP connectionProperties to Driver.connect()

["Justin Cranford (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DBCP-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14988171#comment-14988171 ] 

Justin Cranford commented on DBCP-443:
--------------------------------------

I found a workaround. I am not sure it points to an issue with DBCP or not.

For background, my JDBC stack is: DBCP 2.1 BasicDataSource -> HA-JDBC 3.0.4 DataSource -> MySQL Connector/J 5.1.31

- DBCP2 BasicDataSource config -> Tomcat server.xml (without connectionProperties)
- HA-JDBC DataSource config -> ha-jdbc-mycluster.xml (with connectionProperties)

To workaround the issue with DBCP2 evictor thread not getting connectionProperties, I copied the connectionProperties from my HA-JDBC DataSource config to my DBCP2 BasicDataSource config. After that, DBCP2 evictor thread gets the connectionProperties.


I am not sure if this is expected behaviour for DBCP2 or not. I assumed DBCP2 BasicDataSource used a delegate pattern for all internal JDBC calls (ex: evictor thread) go whatever DataSource object is wraps (ex: a HA-JDBC DataSource instance). That is not the case, though. It seems to be doing delegate calls to a wrapped DataSource instance, but mixing in Driver.connect() calls which are not connected to the delegate DataSource object. By doing Driver.connect() calls, it is establishing new connections and explicitly passing its own connectionProperties instead of reusing what the DataSource already has.

Anyway, I have a workaround. I thought I would let you know so you can decide if this is a DBCP2 issue or not.

> Evictor thread not passing DBCP connectionProperties to Driver.connect()
> ------------------------------------------------------------------------
>
>                 Key: DBCP-443
>                 URL: https://issues.apache.org/jira/browse/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 (http://commons.apache.org/proper/commons-dbcp/changes-report.html) 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() call.
> 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(Driver.java:86)
>                 at org.apache.tomcat.dbcp.dbcp.DriverConnectionFactory.createConnection(DriverConnectionFactory.java:38)
>                 at org.apache.tomcat.dbcp.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:582)
>                 at org.apache.tomcat.dbcp.pool.impl.GenericObjectPool.addObject(GenericObjectPool.java:1617)
>                 at org.apache.tomcat.dbcp.pool.impl.GenericObjectPool.ensureMinIdle(GenericObjectPool.java:1575)
>                 at org.apache.tomcat.dbcp.pool.impl.GenericObjectPool.access$700(GenericObjectPool.java:190)
>                 at org.apache.tomcat.dbcp.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1709)
>                 at java.util.TimerThread.mainLoop(Unknown Source)
>                 at java.util.TimerThread.run(Unknown 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, though.
> Here is my DBCP <Resource>. You can see my connectionProperties for HA-JDBC includes connectTimeout=10000.
>             <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" minEvictableIdleTimeMillis="1800000"
>               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
(v6.3.4#6332)