RockteMQ-AI commented on issue #1325: URL: https://github.com/apache/rocketmq-clients/issues/1325#issuecomment-5238732674
**Issue Evaluation** Category: `type/new feature` | Status: **Evaluated** **Feasibility:** Feasible **Scope:** Java gRPC PushConsumer (`ProcessQueueImpl`, ACK message path) **Compatibility:** No breaking changes — FIFO, Lite consumer, and slow-consumed messages retain immediate ACK behavior. **Assessment:** This is a well-structured proposal for client-side ACK batching. Key strengths: 1. **Protocol-aligned** — The wire protocol already supports repeated `AckMessageRequest.entries`, so this is a client-side optimization with no server changes required. 2. **Concrete design rules** — The batching parameters (1,024 entries, 5s max wait, 25s slow-consume threshold) are specific and testable. 3. **Edge cases addressed** — FIFO ordering, Lite consumer path, shutdown flush, and per-entry error mapping are all explicitly covered. 4. **Validated with benchmarks** — The reported ~95.1% ACK RPC reduction and ~20% CPU savings (both client and Proxy) from a production-like K8s environment provide strong evidence of impact. 5. **Alternatives considered** — The analysis of why cross-topic batching and universal delay are unsuitable demonstrates protocol-level understanding. **Potential implementation considerations:** - Thread safety of the batch accumulator under concurrent consumption - Memory pressure when batching across many topics (1,000+ topic scenarios) - Interaction with `ProcessQueue` lifecycle (drop/clear during rebalance) - Metrics/observability for batch sizes and flush latency This feature is worth pursuing. A PR implementing this would be welcome. --- *Automated evaluation by RockteMQ-AI* -- 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]
