[
https://issues.apache.org/jira/browse/AMQ-9436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817813#comment-17817813
]
ASF subversion and git services commented on AMQ-9436:
------------------------------------------------------
Commit 4bae9df5bdd2b992a716300c70e35dc892f26bd2 in activemq's branch
refs/heads/activemq-5.18.x from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=4bae9df5b ]
AMQ-9436 - Ensure message audit in queue store cursor is shared
This commit fixes the initialization of the StoreQueueCursor message
audit object to make sure it's shared between the persistent and non
persistent cursors. It also adds a check to ensure that duplicate calls
to start will not try and init more than once.
(cherry picked from commit 75de9321162ae096de4a3c0b5a325865d514e5a0)
> StoreQueueCursor creates different audits for persistent and non persistent
> cursors
> -----------------------------------------------------------------------------------
>
> Key: AMQ-9436
> URL: https://issues.apache.org/jira/browse/AMQ-9436
> Project: ActiveMQ Classic
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.18.3, 6.0.1
> Reporter: Christopher L. Shannon
> Assignee: Christopher L. Shannon
> Priority: Major
> Fix For: 6.1.0, 5.18.4, 6.0.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While working on AMQ-9435 I noticed that StoreQueueCursor incorrectly sets
> the start flag to true first before calling calling super.start() in the
> start method. This means that when super is called the message audit is never
> initialized as it thinks it was already started so it stays null forever.
> This causes both the persistent and non-persistent cursors to create their
> own audits which ends up duplicating objects when they should share the same
> audit so we get duplicate detection across persistent and non persistent
> messages and also so that we save memory by not duplicating the objects and
> allowing audit depth config to control how large the audit is.
> Something else I noticed is that the start/stop methods do not protect
> against calling them more than once and they should to prevent duplicate
> initialization so I also will fix that.
> I checked and durables are already correct with their audit tracking (the
> audit is passed down to all of the sub prefetches and shared)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
