commons-issues mailing list archives

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

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

Hassan Sajjad commented on POOL-151:
------------------------------------


Thanks for looking up Mark.

bq. there is no way the same object could get returned to the pool twice

This is verifiable from the {{debug}} log output, as we print session id's when we borrow/return
them from/to the pool. Here's the expanded version of the [earlier log | https://issues.apache.org/jira/browse/POOL-151?focusedCommentId=12765140&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12765140],
showing the second use-case where we may end-up borrowing an *evicted* object. 
PS: I have left some additional info in the log output (Event ID etc) as they may in clarity.

{noformat}
2009-10-13 14:52:13,043 DEBUG [asyncDelivery84] [] [EVENT-ID-28571391-7851-4db8-a691-faf336a52039]
Borrowed session com.ibm.mq.jms.MQQueueSession@1902242 for jms connector moboSub2JmsConnector-LNDSBUS1
2009-10-13 14:52:13,043 DEBUG [asyncDelivery84] [] [EVENT-ID-28571391-7851-4db8-a691-faf336a52039]
Creating a proxy for com.ibm.mq.jms.MQQueueSession@1902242
2009-10-13 14:52:13,943 DEBUG [asyncDelivery84] [] [] Returning session com.ibm.mq.jms.MQQueueSession@1902242
for jms connector moboSub2JmsConnector-LNDSBUS1

2009-10-13 14:52:14,120 DEBUG [asyncDelivery64] [] [EVENT-ID-32e26d85-95c9-4aa5-8ce3-af4eee3ba68f]
Borrowed session com.ibm.mq.jms.MQQueueSession@1902242 for jms connector moboSub2JmsConnector-LNDSBUS1
2009-10-13 14:52:14,121 DEBUG [asyncDelivery64] [] [EVENT-ID-32e26d85-95c9-4aa5-8ce3-af4eee3ba68f]
Creating a proxy for com.ibm.mq.jms.MQQueueSession@1902242
2009-10-13 14:52:14,407 DEBUG [asyncDelivery64] [] [] Returning session com.ibm.mq.jms.MQQueueSession@1902242
for jms connector moboSub2JmsConnector-LNDSBUS1

2009-10-13 14:52:14,875 DEBUG [Timer-0] [] [] Physically closing com.ibm.mq.jms.MQQueueSession@1902242
for connector moboSub2JmsConnector-LNDSBUS1


2009-10-13 14:52:14,876 DEBUG [asyncDelivery64] [] [EVENT-ID-bc393545-9bde-452c-b36c-c8f6a6e0c650]
Borrowed session com.ibm.mq.jms.MQQueueSession@1902242 for jms connector moboSub2JmsConnector-LNDSBUS1
2009-10-13 14:52:14,876 DEBUG [asyncDelivery64] [] [EVENT-ID-bc393545-9bde-452c-b36c-c8f6a6e0c650]
Pool moboSub2JmsConnector-LNDSBUS1 active/idle count is [21/16], ABC [22]
2009-10-13 14:52:14,876 DEBUG [asyncDelivery64] [] [EVENT-ID-bc393545-9bde-452c-b36c-c8f6a6e0c650]
Creating a proxy for com.ibm.mq.jms.MQQueueSession@1902242
2009-10-13 14:52:14,931 FATAL [asyncDelivery64] [] [EVENT-ID-bc393545-9bde-452c-b36c-c8f6a6e0c650]
Failed to dispatch message to audit [javax.jms.IllegalStateException: MQJMS1024: session closed]javax.jms.IllegalStateException:
MQJMS1024: session closed
{noformat}

bq. there is no way the object factory could close an object except in the destroyObject()
method
I can assure there is only single place where the sessions are closed, and that's {{destroyObject}}
method of the factory.

I agree, looking at the {{evict}} method, I don't see how/where this could possibly happen.
The issue could lie in the layer below e.g. the concurrency libraries!?

I'll look into creating a reproducible test case that is decoupled from our client code. May
not be quick though, as it is dependent on threading, concurrent high use etc.



> 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