[jira] [Resolved] (AMQ-6293) Queue destination statistics can be inaccurate with a purge

["Christopher L. Shannon (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AMQ-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christopher L. Shannon resolved AMQ-6293.
-----------------------------------------
       Resolution: Fixed
    Fix Version/s: 5.14.0

Patch applied with a test case.  This can be reopened if there are still issues in the future with wrong counts. 

> Queue destination statistics can be inaccurate with a purge
> -----------------------------------------------------------
>
>                 Key: AMQ-6293
>                 URL: https://issues.apache.org/jira/browse/AMQ-6293
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.13.3
>            Reporter: Christopher L. Shannon
>            Assignee: Christopher L. Shannon
>             Fix For: 5.14.0
>
>
> Recently I have been seeing some negative message counts from the destinationStatistics message counter of a Queue.  The dequeue counts also seem to be wrong as well.  This is hard to reproduce as it happens rarely, but running a purge while there are consumers online acking seems to be an occasional cause. 
> The removeMessage method in a Queue can be called more than once for the same message if an ack comes in at the same time as a purge.  (This is because messages are prefetched so they can be acked even while they are purged) Taking a closer look, the broker handles duplicate calls ok in most cases but there are two areas that need to be fixed.
> First, there is a race condition in the dropMessage() method in Queue.  It checks if the message is dropped before continuing with the drop.  This is not thread safe because the two methods calls are not synchronized together. I was able to show negative counts by introducing a small amount of latency between those two calls during a test.  There needs to be some synchronization done here to prevent the counts from getting out of sync.
> Second, the dequeue counter needs to be moved out of the removeMessage() method and to the dropMessage() method so it can be protected by the same sync and only incremented when a message is dropped to prevent duplicate counts.



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