-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[AMQ-9548] Add attributes to retrieve number of total, non-suppressed and temporary queues and topics #1288
base: main
Are you sure you want to change the base?
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
New MBean operation names look good to me. @mattrpav do you mind to take a new look and approve the PR ?
assert(view.getTotalTemporaryTopicsCount() == 1); | ||
assert(view.getTotalQueuesCount() == 1); | ||
assert(view.getTotalNonSuppressedQueuesCount() == 1); | ||
assert(view.getTotalTemporaryQueuesCount() == 1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
Please use the more appropriate assert* methods.
-
These tests are dodgy. The value expect is 1 and the same across the different types.
-
Multiple commits need to be squashed for this change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll just point out that squashing commits is fine but it is also not necessary. I know I've mentioned before but I prefer it if people do not force push and just push new commits so you can see the difference easier between versions. It's easy to do a squash merge several commits at the end into 1 commit when merging back to main.
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?