You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2016/12/05 12:12:59 UTC

[jira] [Commented] (AMQ-6524) The MemoryUsage tracker can get out of sync when using concurrentStoreAndDispatch

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

ASF subversion and git services commented on AMQ-6524:
------------------------------------------------------

Commit 0f0bdb21ef97c39ec7d54d164e07921611c1de08 in activemq's branch refs/heads/master from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=0f0bdb2 ]

https://issues.apache.org/jira/browse/AMQ-6524

Fixing a thread safety issue with memoryUsage when using concurrentStoreAndDispatch
that was causing memory usage to get out of sync.

The InnerFutureTask class inside KahaDB was not thread safe which was
the root cause of the problem.


> The MemoryUsage tracker can get out of sync when using concurrentStoreAndDispatch
> ---------------------------------------------------------------------------------
>
>                 Key: AMQ-6524
>                 URL: https://issues.apache.org/jira/browse/AMQ-6524
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.14.1
>            Reporter: Christopher L. Shannon
>            Assignee: Christopher L. Shannon
>
> There is a rare issue with memoryUsage when using concurrentStoreAndDispatch that causes memory usage to get out of sync and go negative or stay too high.  It is hard to reproduce and only occurs on brokers under high load in my testing.
> I have finally tracked down the issue to the InnerFutureTask inside of KahaDB that gets used to fire the PendingMarshalUsageTracker on completion.  This task is not thread safe and causes the following 2 problems:
>     
>     1) Sometimes the listener is never fired and the usage isn't decremented. This case seems to be caused by the listener not being visible to the thread when run.  (volatile or atomic reference need to be used)
>     
>     2) Sometimes the listener can run twice. This seems to be because of a lack of synchronization between the if(isDone()) check and the done() method call.  This can also be fixed by using an atomic reference.
> I have a patch that solves both of these problems and I have not seen the issue reoccur in my testing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)