leizhiyuan opened a new issue, #1440: URL: https://github.com/apache/rocketmq-clients/issues/1440
### Before Creating the Bug Report - [x] I found a bug, not just asking a question, which should be created in [GitHub Discussions](https://github.com/apache/rocketmq-clients/discussions). - [x] I have searched the [GitHub Issues](https://github.com/apache/rocketmq-clients/issues) and [GitHub Discussions](https://github.com/apache/rocketmq-clients/discussions) of this repository and believe that this is not a duplicate. - [x] I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ. ### Programming Language of the Client Rust ### Runtime Platform Environment macOS 27 (arm64) ### RocketMQ Version of the Client/Server Client: Rust `rocketmq` 5.0.0, master `a3d1de8b` Server: a managed RocketMQ 5.x service (Tencent Cloud TDMQ for RocketMQ 5), gRPC proxy endpoint ### Run or Compiler Version rustc 1.98.0 ### Describe the Bug `SimpleConsumer::receive` / `receive_with` picks the queue with `select_message_queue`, a plain round-robin over **all** queues of the route, starting at index 0. This differs from Java (`SubscriptionLoadBalancer`) in two ways. 1. **No filtering.** Java only keeps queues that are readable (`READ` / `READ_WRITE`) and served by a master broker (`broker.id == 0`). It fails with "No readable message queue found" when there is none. Rust also sends receive requests to write-only queues, to queues with permission `NONE` (for example while a topic is being scaled in or a broker is read-disabled), and to queues of slave brokers. These requests return nothing or an error, so some of the `receive` calls are wasted. 2. **Fixed start index.** `Route.index` starts at 0 (`TopicRouteManager::query_topic_route`). Java starts at a random index (`RandomUtils.nextInt(0, Integer.MAX_VALUE)`, in both `SubscriptionLoadBalancer` and `PublishingLoadBalancer`). With Rust, every consumer instance (and every restart) begins with the same queue, so load concentrates on the first queues, especially with short-lived consumers that only call `receive` a few times. **Scenario.** Several application instances each start a `SimpleConsumer` and call `receive` in a loop. All of them poll queue 0 first, then queue 1, and so on. If a queue has just been made write-only or not readable, every instance keeps polling it in turn. ### Steps to Reproduce Against `master`, normal topic and group. The route has 18 queues, all readable and on master brokers. Four fresh `SimpleConsumer`s each call `receive_with` four times; the selected queue was logged: ``` queue ids: 0 1 2 0 | 0 1 2 0 | 0 1 2 0 | 0 1 2 0 first queue per consumer: 0, 0, 0, 0 ``` The filtering part needs a route with unreadable or slave queues, which this managed server does not expose; it is confirmed by code review and a unit test. ### What Did You Expect to See? As in Java: only readable master queues are used (error if there is none), and each consumer starts at a random queue. ### What Did You See Instead? All queues are used, and every consumer starts at queue 0. ### Additional Context #1381 adds the same `is_readable_master_queue` check, but only for `LiteSimpleConsumer` (`prune_lite_route`). --- Tracked in #1412. -- 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]
