[#POOL-107] number of connections created has crossed more than maxActive

Commons Pool

number of connections created has crossed more than maxActive

Created: 16/Oct/07 12:06 PM Updated: 12/Aug/09 01:27 PM

Return to search

Component/s:

None

Affects Version/s:

1.3

Fix Version/s:

1.5

Time Tracking:

Not Specified

Environment:

« Hide

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

Resolution Date:

06/Apr/09 03:46 PM

Description

« Hide

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

All

Comments

Work Log

Change History

Subversion Commits

Sort Order:

Repository	Revision	Date	User	Message
ASF	#762396	Mon Apr 06 15:45:37 UTC 2009	markt	Fix ~~POOL-107~~. Narrow synchronisation to where it is needed and ensure that calculations related to pool limits take account of objects we are in the process of making, particularly via the Evictor thread creating minIdle objects. This patch removes a possibility for deadlock (~~DBCP-44~~) but introduces the edge case that where (idle==0 && (active + 1)==maxActive && minIdle>0) a pool may appear to be exhausted to a client if the evictor thread is in the process of creating the last object when the client calls borrowObject(). This is really only an issue if the pool is configured with WHEN_EXHAUSTED_FAIL. The patch also aligns synchronisation strategies between GOP and GKOP. This means less synchronisation in GKOP.
				Files Changed
				MODIFY /commons/proper/pool/trunk/src/java/org/apache/commons/pool/impl/GenericKeyedObjectPool.java MODIFY /commons/proper/pool/trunk/src/java/org/apache/commons/pool/impl/GenericObjectPool.java