commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Thomas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (POOL-151) Eviction thread is able to remove (destroy) in-flight (borrowed) objects
Date Mon, 26 Oct 2009 00:24:59 GMT

    [ https://issues.apache.org/jira/browse/POOL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769888#action_12769888
] 

Mark Thomas commented on POOL-151:
----------------------------------

I've reviewed the code and at the moment, I just can't see how this might happen. All of the
operations that add or remove objects from the pool - including eviction - happen inside sync
blocks. The evictor effectively borrows an object from the pool, tests it and puts it back
if the object passes the tests.

If you could provide a test case that demonstrates this issue that would be extremely helpful.

Whilst I am quite prepared to believe there is still a bug in the pool code somewhere, there
are a couple of ways this could be caused by your own code so it would be good to double check:
a) there is no way the same object could get returned to the pool twice
b) there is no way the object factory could close an object except in the destroyObject()
method

A POOL bug or a) would explain both the log extracts above. b) only explains the second log
extract above.

> Eviction thread is able to remove (destroy) in-flight (borrowed) objects
> ------------------------------------------------------------------------
>
>                 Key: POOL-151
>                 URL: https://issues.apache.org/jira/browse/POOL-151
>             Project: Commons Pool
>          Issue Type: Bug
>    Affects Versions: 1.5.3
>            Reporter: Hassan Sajjad
>            Priority: Blocker
>
> Under high concurrent use, the eviction thread can temper with an in-use object from
the pool, potentially causing catastrophic results, as illustrate in the below log from our
use. Note the object - in our case JMSSession is closed in-flight (after message send but
before commit), causing the commit to fail with {{javax.jms.IllegalStateException: MQJMS1024:
session closed}} error.
> {noformat}
> 2009-10-12 15:08:40,254 DEBUG [asyncDelivery59] Borrowed session com.ibm.mq.jms.MQQueueSession@40bc88
for jms connector 
> 2009-10-12 15:08:40,341 DEBUG [Timer-0] Physically closing com.ibm.mq.jms.MQQueueSession@40bc88
for connector 
> 2009-10-12 15:08:40,669 DEBUG [asyncDelivery59] Returning session com.ibm.mq.jms.MQQueueSession@40bc88
for jms conn
> ector
> 2009-10-12 15:08:40,433 ERROR [asyncDelivery59] Exception caught while committing transaction
[com.ibm.mq.jms.MQQueueSession@40bc88]
> {noformat}

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


Mime
View raw message