activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQCPP-506) Exception "attempt to unlock read lock, not locked by current thread" when doing performance testing
Date Tue, 13 Aug 2013 21:42:48 GMT

    [ https://issues.apache.org/jira/browse/AMQCPP-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13738872#comment-13738872
] 

Timothy Bish commented on AMQCPP-506:
-------------------------------------

I've removed the code for the cached hold counter optimization on trunk for now and added
your test case.  So far I haven't come up with a better low cost optimization strategy for
this so it might be a bit slower although in reality I'm not so sure that will be true.  
                
> Exception "attempt to unlock read lock, not locked by current thread" when doing performance
testing
> ----------------------------------------------------------------------------------------------------
>
>                 Key: AMQCPP-506
>                 URL: https://issues.apache.org/jira/browse/AMQCPP-506
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>          Components: Decaf
>    Affects Versions: 3.7.1
>         Environment: Windows 7
>            Reporter: Jonathan Fortier
>            Assignee: Timothy Bish
>             Fix For: 3.8.0
>
>         Attachments: AMQCPP-506 - UnitTest.patch
>
>
> While doing long-term performance testing of our application (~10,000 messages/second),
an exception is thrown after a few hours of operation. Here is the details of the exception:
> IllegalMonitorStateException: attempt to unlock read lock, not locked by current thread
> Stack trace:
> {quote}
> `anonymous namespace}}'::Sync::tryReleaseShared(int unused=1)  Line 205
> decaf::util::concurrent::locks::AbstractQueuedSynchronizer::releaseShared(int arg=1)
 Line 1630 + 0x11 bytes
> `anonymous namespace'::ReadLock::unlock()  Line 660
> activemq::core::kernels::ActiveMQSessionKernel::lookupConsumerKernel(...)  Line 1336
> activemq::core::ActiveMQSessionExecutor::dispatch(...)  Line 151 + 0x47 bytes
> activemq::core::ActiveMQSessionExecutor::iterate()  Line 182
> activemq::threads::DedicatedTaskRunner::run()  Line 141 + 0x13 bytes
> decaf::lang::Thread::run()  Line 143
> {quote}
> After a little debugging, I identified a code defect that seems to be the cause of our
problem. In class decaf::util::concurrent::locks::ReentrantReadWriteLock, the class member
"cachedHoldCounter" is used to optimize performance. However, that member is accessed concurrently
by multiple thread, but the modifications of that member are not atomic, which implies that
a thread can read a partly updated member (i.e. the count of thread #2 with pointer to thread
#1). In that case, lock logic get all messed up, and we end up with strange behavior (eg.
infinite waiting for lock). 
> I wrote a unit test to reproduce the problem (see attachment). However, since this is
a race condition, it may take a few run to reproduce.
> When I commented cachedHoldCounter-related code from ReentrantReadWriteLock (i.e. always
go in ThreadLocal), the problem seems to be gone. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message