[
https://issues.apache.org/jira/browse/AMQ-9548?focusedWorklogId=939769&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-939769
]
ASF GitHub Bot logged work on AMQ-9548:
---------------------------------------
Author: ASF GitHub Bot
Created on: 23/Oct/24 17:29
Start Date: 23/Oct/24 17:29
Worklog Time Spent: 10m
Work Description: mattrpav commented on code in PR #1288:
URL: https://github.com/apache/activemq/pull/1288#discussion_r1813211735
##########
activemq-broker/src/main/java/org/apache/activemq/broker/jmx/BrokerView.java:
##########
@@ -280,11 +280,21 @@ public ObjectName[] getTopics() {
return safeGetBroker().getTopicsNonSuppressed();
}
+ @Override
+ public int getTotalTopicsCount() {
+ return getTopics().length;
+ }
+
@Override
public ObjectName[] getQueues() {
return safeGetBroker().getQueuesNonSuppressed();
}
+ @Override
+ public int getTotalQueuesCount() {
+ return getQueues().length;
Review Comment:
My proposal is _way_ more useful for users that _use_ suppression, since
they will have a way to know what the actual total number of queues in the
broker actually is. When you use suppression with the current approach, there
is information loss and it isn't useful. The purpose of suppression is to
reduce performance impact of registering JMX beans for objects that are
added/removed quickly.
For mixed (some suppressed, some not) use cases, this is super valuable.
queue://order.> <
Issue Time Tracking
-------------------
Worklog Id: (was: 939769)
Time Spent: 6h (was: 5h 50m)
> Add new broker mbean attributes to directly retrieve total number of queues
> and topics
> --------------------------------------------------------------------------------------
>
> Key: AMQ-9548
> URL: https://issues.apache.org/jira/browse/AMQ-9548
> Project: ActiveMQ Classic
> Issue Type: Improvement
> Components: JMX
> Affects Versions: 5.18.5, 6.1.2
> Reporter: Ken Liao
> Assignee: Ken Liao
> Priority: Major
> Fix For: 6.2.0
>
> Time Spent: 6h
> Remaining Estimate: 0h
>
> Right now, to monitor the number of destination, the only way is to read the
> destinations MBean and get the total destination. However, this means reading
> all destination names into memory, if the user has 10K+ destination with long
> destination name, it will be a large amount of memory just to monitor the
> number of them.
> The proposal here is to add either a new MBean value or a method to obtain
> that data. We can also add a method to retrieve the first K destination as
> well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
