lizhimins commented on issue #1307: URL: https://github.com/apache/rocketmq-clients/issues/1307#issuecomment-5056539724
Closing this enhancement request as **won't-do (in current form)**. While the client-side symptoms described in the summary (latency spike from cache drop, duplicate consumption from failed acks) are real, the proposed drain-based solution creates a broker-side scalability problem that we consider worse than the original client-side issue: **Rolling-shutdown request storm.** During a rolling restart of a large consumer group, every replica shuts down within a short window. If each replica actively drains its cache and waits for in-flight `ReceiveMessage` calls, the aggregated `Ack` / `Nack` / long-poll traffic hits the broker at exactly the time the cluster is also under redeploy pressure. In practice this can amplify the outage-risk window rather than shorten it. The Java implementation ([#992](https://github.com/apache/rocketmq-clients/pull/992) / [#816](https://github.com/apache/rocketmq-clients/issues/816)) has the same characteristic and probably deserves the same reconsideration. A more scalable direction — worth a separate design discussion, not a direct port — would look at: 1. **Stop new receives, but do not drain.** Cancel scanning + close `ReceiveMessage` streams promptly; rely on the broker's invisible-duration to re-deliver whatever was in the local cache (this is at-least-once semantics anyway). 2. **Bound the per-instance shutdown RPC budget.** Cap total ack / nack traffic issued during shutdown, or aggregate acks into batches. 3. **Broker-coordinated shutdown.** Expose an intent-to-shutdown signal so the broker can stop dispatching to a replica before it starts closing its own streams. Withdrawing PR #1308 accordingly. Reopening or a redesign PR is welcome once (2) or (3) is agreed on. -- 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]
