rocketmq proxy里面findOneBroker为什么传clusterName

[yyello206-netizen]

Before Creating the Bug Report

• I found a bug, not just asking a question, which should be created in GitHub Discussions.

• I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.

• I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.

Runtime platform environment

ubantu 20.04 Runtime platform environment: DOCKER

RocketMQ version

5.3.1

JDK Version

1.8

Describe the Bug

@OverRide
protected SubscriptionGroupConfig getDirectly(String consumerGroup) throws Exception {
ProxyConfig config = ConfigurationManager.getProxyConfig();
String clusterName = config.getRocketMQClusterName();
Optional brokerDataOptional = findOneBroker(clusterName);
if (brokerDataOptional.isPresent()) {
String brokerAddress = brokerDataOptional.get().selectBrokerAddr();
return mqClientAPIFactory.getClient().getSubscriptionGroupConfig(brokerAddress, consumerGroup, DEFAULT_TIMEOUT);
}
return EMPTY_SUBSCRIPTION_GROUP_CONFIG;
}

Steps to Reproduce

启动后proxy会报no topic route from namesrv

What Did You Expect to See?

解决这个bug，发布新版本

What Did You See Instead?

很紧急

Additional Context

No response

[RockteMQ-AI]

Issue Evaluation

Category: type/bug | Status: Confirmed

The reported issue has been verified against the current codebase (develop branch).

Root Cause:
findOneBroker(String topic) in ClusterMetadataService is designed to look up brokers by topic route (it calls topicRouteService.getAllMessageQueueView(ctx, topic) internally). However, three CacheLoader.getDirectly() methods pass config.getRocketMQClusterName() (a cluster name like DEFAULT_CLUSTER) instead of a valid topic name:

• ClusterSubscriptionGroupConfigCacheLoader.getDirectly() (line 186)
• ClusterUserCacheLoader.getDirectly() (line 126)
• ClusterAclCacheLoader.getDirectly() (line 139)

Since NameServer has no topic route for the cluster name string, getAllMessageQueueView() returns an empty result, causing the "no topic route from namesrv" error.

Why tests pass: BaseServiceTest.java line 82 explicitly mocks getAllMessageQueueView(any(), eq(CLUSTER_NAME)) to return valid data, masking the real-world failure.

Impact: Proxy fails to load subscription group configs, user ACL data, and user metadata when starting in cluster mode.

Severity: High — affects proxy startup in standard deployments.

Suggested Fix:
Use a known system topic (e.g., MixAll.DEFAULT_TOPIC / TBW102) or topicRouteService.getBrokerAddr() to obtain a broker address, rather than passing the cluster name as a topic to findOneBroker().

---

Automated evaluation by RockteMQ-AI

[RockteMQ-AI]

Fix Proposal (Spec v1)

Approach: Add a new method findOneBrokerInCluster(String clusterName) that uses getBrokerClusterInfo() (NameServer RPC GET_BROKER_CLUSTER_INFO) to correctly discover broker addresses by cluster name, replacing the misuse of findOneBroker(topic) which expects a topic name.

Changes:

1. ClusterMetadataService.java — Add findOneBrokerInCluster() method using mqClientAPIFactory.getClient().getBrokerClusterInfo(), then filter by cluster name from ClusterInfo.getClusterAddrTable()
2. Fix 3 call sites: ClusterUserCacheLoader, ClusterAclCacheLoader, ClusterSubscriptionGroupConfigCacheLoader — replace findOneBroker(clusterName) with findOneBrokerInCluster(clusterName)
3. BaseServiceTest.java — Remove the masking mock when(..., eq(CLUSTER_NAME))
4. ClusterMetadataServiceTest.java — Add proper getBrokerClusterInfo mock

Risk: Low — getBrokerClusterInfo() is a standard NameServer RPC, caches have TTLs so extra round-trips are minimal. findOneBroker() is unchanged (still used correctly by ClusterTopicConfigCacheLoader).

Reply /approve to proceed with PR generation, /revise <feedback> to request changes, or /reject to decline.

---

Automated fix proposal by RockteMQ-AI

[yyello206-netizen]

打算什么时候改

[majialoong]

This is expected behavior, not a bug.

RocketMQ automatically creates a system topic named after the Broker cluster, which Proxy uses to discover a Broker in that cluster.

Please ensure Proxy’s rocketMQClusterName matches the Broker’s brokerClusterName.

[RockteMQ-AI]

Fix Proposal Expired

No feedback was received within the 72-hour window. This automated fix proposal has been closed.

If you'd still like this issue to be addressed, please feel free to reopen the discussion or submit a new proposal.

---

Automated by github-manager-bot