RockteMQ-AI commented on issue #10489:
URL: https://github.com/apache/rocketmq/issues/10489#issuecomment-4709877351

   **Issue Evaluation**
   
   Category: `type/enhancement` | Status: **Evaluated**
   
   **Feasibility:** Feasible, but complex scope
   **Scope:** Proxy layer (gRPC handler), Broker layer (new request code + 
processor), potentially `rocketmq-clients`
   **Compatibility:** New request code — backward compatible. Older brokers 
will reject the batch request; Proxy should fall back to individual calls.
   
   This is a meaningful optimization for scenarios with bulk invisible time 
changes (client disconnect, write-back failure, periodic renewal). The proposal 
to follow the existing `BatchAck` pattern is sound.
   
   Key considerations:
   - **Batch size limit** — Need a configurable upper bound to prevent 
oversized requests.
   - **Partial failure semantics** — If some messages in the batch fail, should 
the whole batch rollback or return per-message results?
   - **RocksDB flush reduction** — The batch write should use a single 
`WriteBatch` to amortize flush cost.
   - **Client SDK coordination** — If the Java/Go/C++ clients need to call this 
directly, protocol changes in `rocketmq-clients` are needed.
   
   This is a larger feature that benefits from a design discussion before 
implementation. A RIP (RocketMQ Improvement Proposal) or detailed design doc 
would help align on the approach.
   
   ---
   *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]

Reply via email to