iloveeyjafjalla opened a new issue, #6858:
URL: https://github.com/apache/rocketmq-dashboard/issues/6858
### Studio Version
branch: `rocketmq-studio` @ `a92c2314`
### Runtime Environment
The repository's own stack: backend on 8888 against its MySQL, the console
on the dev server, one Apache instance (`local-broker`) pointing at a
NameServer that serves a broker on 127.0.0.1:10911 (image
`apache/rocketmq:5.3.2`).
### Connected RocketMQ Cluster
RocketMQ 5.3.2 broker, direct to NameServer (V4_DIRECT).
### Describe the Bug
The overview counts the two topics a broker creates for its own cluster as
user topics. `GET /api/dashboard?instanceId=local-broker` answers `totalTopics:
32` (and `clusters[0].topics: 32`) while the broker holds 30 user topics:
```
$ mqadmin topicList -n rmq-nameserver:9876 # 46 names, including
DefaultCluster (16 read / 16 write queues, cluster topic)
DefaultCluster_REPLY_TOPIC ( 1 read / 1 write queue, reply topic)
...
```
`TopicConfigManager#init` creates both while the broker starts, and
registers each with `TopicValidator.addSystemTopic`:
```java
{
String topic =
this.brokerController.getBrokerConfig().getBrokerClusterName();
TopicConfig topicConfig = new TopicConfig(topic);
TopicValidator.addSystemTopic(topic);
...
}
{
String topic =
this.brokerController.getBrokerConfig().getBrokerClusterName() + "_" +
MixAll.REPLY_TOPIC_POSTFIX;
TopicConfig topicConfig = new TopicConfig(topic);
TopicValidator.addSystemTopic(topic);
...
}
```
That registration is **per JVM**, so Studio - a separate process - never
inherits it: `SystemTopicFilter.isSystem` delegates to
`TopicValidator.isSystemTopic`, whose static set does not contain either name,
and the two leak into every count and list built from live broker topics. The
console already needed exactly this registration for its topic statistics once
(#82 / #83), and the studio's shared filter lost it.
### Steps to Reproduce
1. Start the stack against a broker that has topics.
2. `curl 'http://127.0.0.1:8888/api/dashboard?instanceId=local-broker'` ->
`"totalTopics": 32`, `"topics": 32` for `DefaultCluster`.
3. `mqadmin topicList -n <nameserver>` shows `DefaultCluster` and
`DefaultCluster_REPLY_TOPIC` among the 46 names; the studio's own topic
inventory holds 30 topics that exist on the broker.
4. A filter probe over the real broker names keeps both (32 kept) instead of
dropping them (30 kept).
### What Did You Expect to See?
Both names are topics the broker generated for itself, not user topics, so
they are excluded from the topic counts and from any list built from live
broker metadata: `totalTopics` and `clusters[].topics` answer 30 for this stack.
### What Did You See Instead?
They are counted: the overview reports two more topics than the cluster
holds, and the same two names would surface in any live-broker topic listing.
### Additional Context
The fix only matches the owning cluster's two names, so a user topic that
merely ends in the reply suffix, or carries another cluster's name, stays a
user topic.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
