[
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.mqqueuesess...@40bc88 for jms connector
> 2009-10-12 15:08:40,341 DEBUG [Timer-0] Physically closing
> com.ibm.mq.jms.mqqueuesess...@40bc88 for connector
> 2009-10-12 15:08:40,669 DEBUG [asyncDelivery59] Returning session
> com.ibm.mq.jms.mqqueuesess...@40bc88 for jms conn
> ector
> 2009-10-12 15:08:40,433 ERROR [asyncDelivery59] Exception caught while
> committing transaction [com.ibm.mq.jms.mqqueuesess...@40bc88]
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
