[AMQ-9548] Add attributes to retrieve number of total, non-suppressed and temporary queues and topics #1288
Conversation
activemq-broker/src/main/java/org/apache/activemq/broker/jmx/BrokerView.java
Outdated
Show resolved
Hide resolved
activemq-broker/src/main/java/org/apache/activemq/broker/jmx/BrokerView.java
Outdated
Show resolved
Hide resolved
activemq-broker/src/main/java/org/apache/activemq/broker/jmx/BrokerViewMBean.java
Show resolved
Hide resolved
|
I took a look at this and I agree with Matt for all the points he made. The suppression configuration here is because of performance reasons. You are suppressing the returned queue metrics over JMX to not overload things. That doesn't mean the queues don't exist or are not valid so I don't think it makes sense to hide suppressed queues from the metrics. On the other hand I get JB's point about it could be a little confusing if getQueues() is returning a different number because of the suppression. So if I had to pick one I would agree with @mattrpav and say we should return total queues. However, why not just provide both and call it a day? Just provide both a total count for the broker of the over all queue count and also an un-suppressed count metric. We could have something like getTotalQueueCount() and getUnsupressedQueueCount() or something like that. The total queues just can just use the map size with is a fast constant operation as @mattrpav pointed out. For suppressed queues you could iterate over the queues in the map and count them to avoid object allocation on the broker side, or we could just keep a counter that keeps a running total on queue adds/deletes. |
|
Also the naming doesn't matter, can pick whatever makes sense. The point is just provide both metrics as they could both be useful but make sure we compute them without a bunch of memory allocation |
|
Ok fair enough. I propose to add the two operations as I'm sure users will need both. |
kenliao94
changed the title
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 several attributes so customer application can just query the total number of unsuppressed, total, and temporary 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?