RockteMQ-AI commented on issue #1315: URL: https://github.com/apache/rocketmq-clients/issues/1315#issuecomment-5105894375
**Issue Evaluation** Category: `type/enhancement` | Status: **Evaluated — Needs Discussion** Thank you for the detailed proposal. The motivation is valid — the current `SimpleConsumer.receive()` internally round-robins across queues via `SubscriptionLoadBalancer`, so callers cannot deterministically cover all queues without knowing the route topology. **Feasibility:** Technically feasible. The internal building blocks already exist: - `TopicRouteData` and `MessageQueueImpl` in `java/client/.../route/` - Route fetching via `ClientImpl.getRouteData(topic)` - Queue-level receive via `wrapReceiveMessageRequest` / `receiveMessage` in `SimpleConsumerImpl` **Scope of changes:** - A new public `MessageQueue` interface in `client-apis` (cannot expose `MessageQueueImpl` directly — it leaks internal types like `Broker`, `Permission`, protobuf) - Two `default` methods on `SimpleConsumer`: e.g. `getMessageQueues(String topic)` and `receiveAsync(MessageQueue, int, Duration)` - Implementation in `SimpleConsumerImpl` (~15-30 lines reusing existing internals) - Tests + example **Key concerns that need community discussion before implementation:** 1. **Cross-language API contract** — `client-apis` is designed to mirror the shared rocketmq-apis spec across Java/C++/C#/Go/Rust clients. Adding queue-awareness to `SimpleConsumer` in Java alone would diverge from the multi-language spec. This should be discussed on the dev mailing list first. 2. **Semantic shift** — `SimpleConsumer` intentionally hides queue details (server-side load balancing via consumer group). Queue-pinned receive can skew consumption distribution and interacts unexpectedly with shared consumer groups. 3. **Staleness** — Routes change dynamically (queue migration, permission changes). A caller-held `MessageQueue` reference can become stale; error semantics need to be defined. 4. **Alternative approach** — Consider exposing only the queue *count* (or a "desired concurrency" hint), which addresses the stated motivation without leaking queue identity or changing the core API contract. **Recommendation:** This is a meaningful enhancement, but given its impact on the public API surface and cross-language consistency, it would benefit from discussion on the [dev mailing list]([email protected]) before a PR is opened. --- *Automated evaluation by github-manager-bot* -- 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]
