qianye1001 opened a new pull request, #10408:
URL: https://github.com/apache/rocketmq/pull/10408

   ## Summary
   
   - Fix `ConsumeMessageOrderlyService.sendMessageBack()` and 
`ConsumeMessagePopOrderlyService.sendMessageBack()` to route retry messages to 
brokers that actually host the original topic, instead of falling back to 
TBW102 which routes to all brokers in the cluster.
   
   ## Root Cause
   
   When an orderly consumer's reconsume times reach `maxReconsumeTimes`, 
`sendMessageBack()` sends the retry message via 
`getDefaultMQProducer().send(newMsg)` — a normal producer send. Since the 
`%RETRY%` topic doesn't exist yet, the producer falls back to TBW102 (a system 
topic present on ALL brokers) for broker selection. This causes the `%RETRY%` 
topic to be auto-created on brokers that don't host the original topic.
   
   **Contrast with concurrent consumers**: `ConsumeMessageConcurrentlyService` 
uses `consumerSendMsgBack` which targets `msg.getBrokerName()` directly — no 
TBW102 fallback.
   
   ## Fix
   
   Added `trySendToTopicBroker()` to both orderly service classes. It uses the 
consumer's existing `topicSubscribeInfoTable` (route info for the original 
topic) to select candidate brokers:
   
   1. **Prefer original broker** — the broker where the message was consumed
   2. **Failover to other brokers hosting the topic** — if the original broker 
is down
   3. **Final fallback to default send** — only when route info is unavailable 
(should not happen in practice)
   
   ## Impact
   
   | Scenario | Before | After |
   |---|---|---|
   | Original broker alive | May route to any broker (TBW102) | Routes to 
original broker ✓ |
   | Original broker down | Routes to any broker | Failover to other brokers 
hosting the topic ✓ |
   | All topic brokers down | Routes to any broker | Same (fallback) |
   
   No behavioral change for brokers that DO host the original topic. Backward 
compatible.
   
   ## Test plan
   
   - [ ] Verify `trySendToTopicBroker` prefers the original broker when 
available
   - [ ] Verify failover to another broker when original broker send fails
   - [ ] Verify fallback to default send when route info is empty
   - [ ] Integration test: proxy cluster mode with multi-broker, orderly 
consumer hitting maxReconsumeTimes — `%RETRY%` should only appear on brokers 
hosting the original topic
   
   Closes #10405
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)


-- 
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]

Reply via email to