[
https://issues.apache.org/jira/browse/AMQ-9436?focusedWorklogId=905173&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-905173
]
ASF GitHub Bot logged work on AMQ-9436:
---------------------------------------
Author: ASF GitHub Bot
Created on: 15/Feb/24 22:31
Start Date: 15/Feb/24 22:31
Worklog Time Spent: 10m
Work Description: cshannon opened a new pull request, #1154:
URL: https://github.com/apache/activemq/pull/1154
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.
Issue Time Tracking
-------------------
Worklog Id: (was: 905173)
Remaining Estimate: 0h
Time Spent: 10m
> 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: 10m
> 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)