[
https://issues.apache.org/jira/browse/POOL-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239526#comment-13239526
]
Dmytro Savchenko commented on POOL-107:
---------------------------------------
The problem is reproduced exact as described by Victor N with commons-dbcp-1.4
and commons-pool-1.6. Pool should be created prior to DB became available.
There is a problem method in org.apache.commons.dbcp.BasicDataSource class:
protected void createConnectionPool() {
// Create an object pool to contain our active connections
GenericObjectPool gop;
if ((abandonedConfig != null) &&
(abandonedConfig.getRemoveAbandoned())) {
gop = new AbandonedObjectPool(null,abandonedConfig);
}
else {
gop = new GenericObjectPool();
}
gop.setMaxActive(maxActive);
gop.setMaxIdle(maxIdle);
gop.setMinIdle(minIdle);
gop.setMaxWait(maxWait);
gop.setTestOnBorrow(testOnBorrow);
gop.setTestOnReturn(testOnReturn);
gop.setTimeBetweenEvictionRunsMillis(timeBetweenEvictionRunsMillis);
gop.setNumTestsPerEvictionRun(numTestsPerEvictionRun);
gop.setMinEvictableIdleTimeMillis(minEvictableIdleTimeMillis);
gop.setTestWhileIdle(testWhileIdle);
connectionPool = gop;
}
When client application calls getConnection() method there will be an attempt
to create real data source. There are some steps that will be performed:
1) createConnectionPool() creates connection pool and starts evictor thread if
minEvictableIdleTimeMillis > 0. This additional thread will clean up pool and
create new connections to met the "minIdle" connection count if it's > 0.
2) createPoolableConnectionFactory() will create connection factory. And pool
created on previous step will get this factory. After that evictor will start
trying to get the number of connections defined by "minIdle" parameter even if
DB is unavailable.
The problem appears is on step 1. If (connectionPool != null) we will lose
previously created pool with connection factory set and evictor started. And
this happens every time BasicDataSource::getConnection() method is called.
So, when DB will became available there will be a lot of lost connection pools
each trying to get the minIdle connections.
We've solved this by extending BasicDataSource and overriding of
createConnectionPool method in such a way:
protected void createConnectionPool()
{
if (connectionPool != null)
{
try
{
connectionPool.close();
}
catch (Exception e)
{
}
}
super.createConnectionPool();
}
> number of connections created has crossed more than maxActive
> --------------------------------------------------------------
>
> Key: POOL-107
> URL: https://issues.apache.org/jira/browse/POOL-107
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 1.3
> Environment: OS:Red Hat Enterprise Linux AS release 4 (Nahant Update
> 2)
> uname:Linux 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:32:14 EDT 2005 i686
> vm_info: Java HotSpot(TM) Server VM (1.4.2_13-b06) for
> linux-x86, built
> on Oct 18 2006 09:55:11 by unknown with unknown compiler
> Reporter: Bhaskar NA
> Fix For: 1.5
>
>
> I found that when the minIdle is configured then during loads, common pool
> creates more number of connections it will be greater than maxActive.
> When I had following settings:
> maxActive = 50
> maxIdle = 30
> minIdle=30
> factory=org.apache.commons.dbcp.BasicDataSourceFactory
> maxWait=10000
> timeBetweenEvictionRunsMillis=900000
> numTestsPerEvictionRun=50
> minEvictableIdleTimeMillis=1800000
> testWhileIdle=true
> testOnBorrow = true
> validationQuery='select 1 from dual'
> Number of connections in the pool went upto 121. (found thru netstat)
> When I changed minIdle to 15 and did my load test connecitons in the pool
> went upto 66
> Looks like maxActive is getting bypassed with minIdle.
> When I changed minIdle to 10 and maxActive to 30 and maxIdle to 30 then
> number of connections went upto 40.
> Can someone please throw light on what is going on here? I am using DBCP
> 1.2.1 and common pool 1.3.
> Bhaskar
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
