[AMQ-8463] Add advancedMessageStatistics feature

[mattrpav]

Reviewer notes:

• New AdvancedMessageStatisticsEnabled flag per-policyEntry (default: false)
• No new timestamp sampling added (ie no new System.currentTimeMillis() calls)
• Values reset on resetStatistics
• Values exposed via JMX
• Enqueue Message BrokerInTime, ClientID, MessageID and MessageTimestamp fields
• Dequeue Message BrokerInTime, BrokerOutTime, ClientID, MessageID and MessageTimestamp fields
• Unit test for policyEntry runtime configuration modification
• Unit test for functional testing including network include/exclude verification
• Non-durable topics do not have brokerInTime or messageTimestamp in scope during dequeue, so those values will always be zero (0)

[cshannon]

One thing I noticed is the new statistic impl classes all are copy and pasted code, it seems like you could just re-use all of that if you used generics.

[cshannon]

I know this would be a much bigger effort but if we intend to keep adding more and more metrics, from a performance and maintainability standpoint, we should really look into moving everything to Micrometer which adds more more flexibility and should be better performance. That kind of change would likely end up being a major version, ie AMQ 7.0 if we wanted to do that.

[cshannon]

We should not be compromising correctness for performance. If this is multi-threaded you need to make it thread safe. Furthermore, the impact of volatile is going to be negligible in the real world.

You could use AtomicReference and make this final

[mattrpav]

I'm thinking 'volatile' over AtomicReference. Same thread-safety, fewer objects created.

[cshannon]

I don't think the extra object creation matters in this case and the extra features of the atomic classes are nice. One thing i just realized was that if we want to use other Atomic classes like AtomicLong, which would be nice, then we may not be able to use generics after all as that atomic type needs to be different and we'd have slightly different code

[tabish121]

Depending on the use case this is what static atomic field updater types are for, all the features like CAS but only one static allocation.

[cshannon]

You don't need these interfaces if you just use generics as I mentioned in my other comment.

[mattrpav]

Yeah, I think this could be changed, but I'm wondering if it gets verbose to the consumer of the metric. I felt my original approach was "following the as-is" vs getting to the optimal target state.

If we go generic, do we add a generic parameter for all the dimensions? Sampled, Summed, Ranged, Fixed value, etc?

I think the interfaces do a good job of communicating the type. Feels like adding generics just pushes the type info to the consuming service code.

   public UnsampledStatisticImpl<Long> getDequeuedMessageBrokerOutTime() {
        return dequeuedMessageBrokerOutTime;
    }

I'm not married to either approach.

[cshannon]

I think it mostly depends on if the different types will have any logic that is different or needs to be overriden. You could also move common code into an abstract class if needed, I was just noticing a lot of copy/paste and seemed like generics could be useful.