[
https://issues.apache.org/jira/browse/AMQ-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15283595#comment-15283595
]
ASF subversion and git services commented on AMQ-6293:
------------------------------------------------------
Commit 1241e4120a5f4af58be2952a6ec985dcd8ac11c3 in activemq's branch
refs/heads/master from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=1241e41 ]
https://issues.apache.org/jira/browse/AMQ-6293
Fixing Queue destination statistics in dropMessage by adding sync in
between the check for dropped and actually dropping the message plus
fixing dequeue stats so messages aren't counted twice
> 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
>
> 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)
