You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Nick Brachet (JIRA)" <ji...@apache.org> on 2010/03/26 15:54:27 UTC
[jira] Created: (DBCP-328) exponential wait when requesting
connections while the database is down
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:
1- 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.
2- 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:
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);
}
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.
[jira] Updated: (DBCP-328) exponential wait when requesting
connections while the database is down
Posted by "Nick Brachet (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (DBCP-328) exponential wait when requesting
connections while the database is down
Posted by "Nick Brachet (JIRA)" <ji...@apache.org>.
[ 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:
1- 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.
2- 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.
was:
2 problems in one but they are very related:
1- 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.
2- 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:
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);
}
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:
> 1- 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.
> 2- 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DBCP-328) exponential wait when requesting
connections while the database is down
Posted by "Nick Brachet (JIRA)" <ji...@apache.org>.
[ 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 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:
1- 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.
2- 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 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.
[jira] Closed: (DBCP-328) exponential wait when requesting
connections while the database is down
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Steitz closed DBCP-328.
----------------------------
Resolution: Duplicate
Duplicates 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.