Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Fri, 31 Jul 2015 05:10:04 +0000 (UTC)
From: "Phil Steitz (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12850265.1438265959000.337247.1438319404781@Atlassian.JIRA>
In-Reply-To: <JIRA.12850265.1438265959000@Atlassian.JIRA>
References: <JIRA.12850265.1438265959000@Atlassian.JIRA>
 <JIRA.12850265.1438265959516@arcas>
Subject: [jira] [Commented] (DBCP-443) Evictor thread not passing DBCP
 connectionProperties to Driver.connect()
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Phil Steitz commented on DBCP-443:
----------------------------------

Can you see the other properties in the stack trace above?  I assume username and password at least must be going. At this point, I would suspect a driver thread-safety issue.  Have you tried upgrading to the latest version of the driver that you can use (I mean net.sf.hajdbc.sql.Driver version here, not the underlying mysql driver)?  

> 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)