Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <1936823391.510661269615987236.JavaMail.jira@brutus.apache.org>
Date: Fri, 26 Mar 2010 15:06:27 +0000 (UTC)
From: "Nick Brachet (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Updated: (DBCP-328) exponential wait when requesting
 connections while the database is down
In-Reply-To: <1987097850.510431269615267341.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DBCP-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nick Brachet updated DBCP-328:
------------------------------

    Description: 
2 problems in one but they are very related:

# When the database is down (the actual server/machine, not the MySQL instance) the JDBC driver will wait {{connectTimeout}} before timing out. {{BasicDataSource.createDataSource()}}, which calls {{validateConnectionFactory()}} when it initializes, is synchronized. So each threads are waiting on the synchronize lock so they can all then wait {{connectTimeout}} before finally timing out.
Imagine a 5sec {{connectTimeout}} and 10 concurrent theads, the last thread will timeout after roughly 50 seconds.
# Similarly when the database dies (again the actual server/machine, not the instance), after {{BasicDataSource}} has initialized, the JDBC driver will again wait {{connectTimeout}} before timing out when new connections are created to grown the pool. {{PoolableConnectionFactory#makeObject()}}, which calls {{createConnection()}}, is also synchronized causing the same exponential wait for any threads requesting a connection from the pool.
Maybe I should explain that Connector/J closes the actual connection when it detects a communication failure with the database, and the connection is then removed from the pool. So when the database server dies the pool gets depleted and new connections need to be created.

I am not sure how to address #1 easily but #2 can be addressed by calling {{createConnection()}} outside of any locks.
For example:
{noformat}
    public Object makeObject() throws Exception {
        ConnectionFactory connFactory;
        KeyedObjectPoolFactory stmtPoolFactory;
        ObjectPool pool;
        synchronized (this) {
            connFactory = _connFactory;
            stmtPoolFactory = _stmtPoolFactory;
            pool = _pool;
        }
        Connection conn = connFactory.createConnection();
        if(null != stmtPoolFactory) {
            KeyedObjectPool stmtpool = stmtPoolFactory.createPool();
            conn = new PoolingConnection(conn,stmtpool);
            stmtpool.setFactory((PoolingConnection)conn);
        }
        return new PoolableConnection(conn,pool,_config);
    }
{noformat}
Although there may be some problem if the pool is swapped while creating a connection...

See also dbcp-300.

  was:
2 problems in one but they are very related:

# When the database is down (the actual server/machine, not the MySQL instance) the JDBC driver will wait {{connectTimeout}} before timing out. {{BasicDataSource.createDataSource()}}, which calls {{validateConnectionFactory()}} when it initializes, is synchronized. So each threads are waiting on the synchronize lock so they can all then wait {{connectTimeout}} before finally timing out.
Imagine a 5sec {{connectTimeout}} and 10 concurrent theads, the last thread will timeout after roughly 50 seconds.
# Similarly when the database dies (again the actual server/machine, not the instance), after {{BasicDataSource}} has initialized, the JDBC driver will again wait {{connectTimeout}} before timing out when new connections are created to grown the pool. {{PoolableConnectionFactory#makeObject()}}, which calls {{createConnection()}}, is also synchronized causing the same exponential wait for any threads requesting a connection from the pool.
Maybe I should explain that Connector/J closes the actual connection when it detects a communication failure with the database, and the connection is then removed from the pool. So when the database server dies the pool gets depleted and new connections need to be created.

I am not sure how to address #1 but #2 can be addressed by calling {{createConnection()}} outside of any locks.
For example:
{noformat}
    public Object makeObject() throws Exception {
        ConnectionFactory connFactory;
        KeyedObjectPoolFactory stmtPoolFactory;
        ObjectPool pool;
        synchronized (this) {
            connFactory = _connFactory;
            stmtPoolFactory = _stmtPoolFactory;
            pool = _pool;
        }
        Connection conn = connFactory.createConnection();
        if(null != stmtPoolFactory) {
            KeyedObjectPool stmtpool = stmtPoolFactory.createPool();
            conn = new PoolingConnection(conn,stmtpool);
            stmtpool.setFactory((PoolingConnection)conn);
        }
        return new PoolableConnection(conn,pool,_config);
    }
{noformat}
Although there may be some problem if the pool is swapped while creating a connection...

See also dbcp-300.


> exponential wait when requesting connections while the database is down
> -----------------------------------------------------------------------
>
>                 Key: DBCP-328
>                 URL: https://issues.apache.org/jira/browse/DBCP-328
>             Project: Commons Dbcp
>          Issue Type: Bug
>    Affects Versions: 1.2.2
>         Environment: Tomcat Apache 5.5.28
> MySQL 5.1 / Connector/J 5.1.5
> JDK 1.5.0_22
>            Reporter: Nick Brachet
>
> 2 problems in one but they are very related:
> # When the database is down (the actual server/machine, not the MySQL instance) the JDBC driver will wait {{connectTimeout}} before timing out. {{BasicDataSource.createDataSource()}}, which calls {{validateConnectionFactory()}} when it initializes, is synchronized. So each threads are waiting on the synchronize lock so they can all then wait {{connectTimeout}} before finally timing out.
> Imagine a 5sec {{connectTimeout}} and 10 concurrent theads, the last thread will timeout after roughly 50 seconds.
> # Similarly when the database dies (again the actual server/machine, not the instance), after {{BasicDataSource}} has initialized, the JDBC driver will again wait {{connectTimeout}} before timing out when new connections are created to grown the pool. {{PoolableConnectionFactory#makeObject()}}, which calls {{createConnection()}}, is also synchronized causing the same exponential wait for any threads requesting a connection from the pool.
> Maybe I should explain that Connector/J closes the actual connection when it detects a communication failure with the database, and the connection is then removed from the pool. So when the database server dies the pool gets depleted and new connections need to be created.
> I am not sure how to address #1 easily but #2 can be addressed by calling {{createConnection()}} outside of any locks.
> For example:
> {noformat}
>     public Object makeObject() throws Exception {
>         ConnectionFactory connFactory;
>         KeyedObjectPoolFactory stmtPoolFactory;
>         ObjectPool pool;
>         synchronized (this) {
>             connFactory = _connFactory;
>             stmtPoolFactory = _stmtPoolFactory;
>             pool = _pool;
>         }
>         Connection conn = connFactory.createConnection();
>         if(null != stmtPoolFactory) {
>             KeyedObjectPool stmtpool = stmtPoolFactory.createPool();
>             conn = new PoolingConnection(conn,stmtpool);
>             stmtpool.setFactory((PoolingConnection)conn);
>         }
>         return new PoolableConnection(conn,pool,_config);
>     }
> {noformat}
> Although there may be some problem if the pool is swapped while creating a connection...
> See also dbcp-300.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.