[AMQ-9548] Add attributes to display total number of queues and topics #1288
Conversation
| @Override | ||
| public ObjectName[] getQueues() { | ||
| return safeGetBroker().getQueuesNonSuppressed(); | ||
| } | ||
|
|
||
| @Override | ||
| public int getTotalQueuesCount() { | ||
| return getQueues().length; |
There was a problem hiding this comment.
This still calls a method that creates a new array of objects. Why not just return the value of the size from the map?
There was a problem hiding this comment.
Good callout, I believe the new array of objects you are referring to is the one created in onlyNonSuppressed which copy over the non suppressed queues or topics already maintained in the ManagedRegionBroker. Are you saying I should just simply return the size of private final Map<ObjectName, DestinationView> queues = new ConcurrentHashMap<>(); in ManagedRegionBroker?
My concern is that it will not agree with the queue or topic list in the queues and topics MBean attribute, and those are non suppressed which should be the correct list.
The optimization done at this PR is mainly for user application. Because they will need to read that ObjectName array into their memory space even all they need is the count of queues or topics. So if this PR is merged as it is, the user application memory space will not be bloated (even tho as your pointed out, on the broker side, it will still need to create an array of those objects on the broker process memory space).
WDYT?
What problems does this PR solve?
Currently, to get the total number of queues and topics on the broker using JMX, one needs to query the attribute values of Queues and Topics on the broker MBean then post-process it (finding the length of returned array) to get that data. This can be resource intensive (unnecessary copy of the data) on the customer application using JMX or Jolokia if user has tens or thousands of destinations and all the user wants is the number. Hence this PR added two attributes so customer application can just query the total number without getting the list of topics and queues first.
Why is it beneficial to merge into ActiveMQ?
This will be beneficial for users with high number of destinations. They can now monitor the total number of queues and topics in a more performant way.
How do you make sure this PR is well tested?