[AMQ-9436] StoreQueueCursor creates different audits for persistent and non persistent cursors

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 5.18.3, 6.0.1
• Fix Version/s: 6.1.0, 5.18.4, 5.17.7, 6.0.2
• Component/s: Broker
• Assignee: Christopher L. Shannon
• Reporter: Christopher L. Shannon
• Created: 15/Feb/24 22:27
• Updated: 15/Feb/24 23:21
• Resolved: 15/Feb/24 23:21

Description

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)