[ 
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)

Reply via email to