commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [POOL] Ready for 1.5.6
Date Sun, 27 Mar 2011 17:29:19 GMT
On 3/24/11 4:34 AM, Mark Thomas wrote:
> On 23/03/2011 20:01, Mark Thomas wrote:
>> On 23/03/2011 19:54, Phil Steitz wrote:
>>> On 3/23/11 12:36 PM, Mark Thomas wrote:
>>>> Phil,
>>>>
>>>> I believe all the pool issues for 1.5.x have been resolved. Over to
>>>> you... :)
>>>>
>>> Thanks!  You are awesome, Mark!
>>>
>>> I will finish reviewing your last set of commits and then roll an RC.
>>>
>>> Did you see my (hopefully baseless) memory leak fear about the fix
>>> for POOL-181?
>> I just did. My mail was slow this afternoon. Looking at it now. I think
>> a few changes will be required.
> Changes complete and test cases updated. I think we are good to go now.
>
I saw the following in a thread dump during execution of one of my
soak tests (the one that led to POOL-180).  While there is no
deadlock, it does violate our invariant that factory methods should
not be invoked within pool-synchronized scope and kills pool
performance when destroy has latency:

java] "pool-1-thread-115" prio=5 tid=102a3a800 nid=0x111857000
waiting on condition [111856000]
     [java]    java.lang.Thread.State: TIMED_WAITING (sleeping)
     [java]     at java.lang.Thread.sleep(Native Method)
     [java]     at
org.apache.commons.performance.pool.WaiterFactory.doWait(Unknown Source)
     [java]     at
org.apache.commons.performance.pool.WaiterFactory.destroyObject(Unknown
Source)
     [java]     at
org.apache.commons.performance.pool.WaiterFactory.destroyObject(Unknown
Source)
     [java]     at
org.apache.commons.pool.impl.GenericKeyedObjectPool.destroy(GenericKeyedObjectPool.java:1470)
     [java]     at
org.apache.commons.pool.impl.GenericKeyedObjectPool.clearOldest(GenericKeyedObjectPool.java:1424)
     [java]     at
org.apache.commons.pool.impl.GenericKeyedObjectPool.allocate(GenericKeyedObjectPool.java:1330)
     [java]     at
org.apache.commons.pool.impl.GenericKeyedObjectPool.addObjectToPool(GenericKeyedObjectPool.java:1642)
     [java]     - locked <7f44e1950> (a
org.apache.commons.pool.impl.GenericKeyedObjectPool)
     [java]     at
org.apache.commons.pool.impl.GenericKeyedObjectPool.returnObject(GenericKeyedObjectPool.java:1556)
     [java]     at
org.apache.commons.performance.pool.PoolClientThread.execute(Unknown
Source)
     [java]     at
org.apache.commons.performance.ClientThread.run(Unknown Source)
     [java]     at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
     [java]     at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
     [java]     at java.lang.Thread.run(Thread.java:680)


The problem is that addObjectToPool calls allocate within a synch
block and while allocate itself lets go of its lock before calling
destroy, the end result is factory destroy called while holding the
pool lock.

Phil
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message