lizhimins commented on PR #1308: URL: https://github.com/apache/rocketmq-clients/pull/1308#issuecomment-5056534321
Closing this PR — after further review the "drain cached messages + wait for inflight receives" approach has a scalability concern that outweighs the client-side benefit: **Problem: broker request storm on rolling shutdowns.** The draining phases keep the consumer actively talking to the broker until every cached message is acked and every in-flight `ReceiveMessage` returns. During a rolling restart / blue-green deploy of a large consumer group, every replica shuts down within a short window and each one: 1. Keeps issuing `Ack` / `Nack` RPCs while it drains its local cache. 2. Keeps holding open `ReceiveMessage` long-polling streams until they naturally return. Aggregated across thousands of consumer instances shutting down simultaneously, this produces a spike of ack / long-poll traffic **exactly when the broker is also under redeploy pressure**. The broker-side cost of this can be much higher than the client-side benefit (avoiding a bounded latency bump for cached messages, which the broker's invisible-duration re-delivery already handles). The Java implementation (#992 / #816) has the same characteristic and should probably be revisited under a broader "graceful shutdown at scale" design that: - Prioritizes stopping new `ReceiveMessage` requests over draining cached ones. - Bounds the total shutdown-time RPC volume per instance. - Coordinates with the broker on the desired shutdown budget. Rather than porting a design that we now believe needs to be reworked, I'm withdrawing this PR. Happy to reopen a redesigned version under a fresh issue if there is interest. /cc #1307 -- 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]
