RockteMQ-AI commented on issue #10538: URL: https://github.com/apache/rocketmq/issues/10538#issuecomment-4767117485
**Issue Evaluation** Category: `type/enhancement` | Status: **Evaluated** **Feasibility:** Feasible **Scope:** `client` module (`MQClientAPIImpl`, `DefaultMQProducerImpl`), `remoting` module (`SendMessageRequestHeader`, `SendMessageRequestHeaderV2`) **Compatibility:** Low risk — V2 header encoding is internal to the remoting protocol; wire format remains unchanged. The analysis is correct. `SendMessageRequestHeaderV2` currently acts as an intermediate object with 14 short-named fields (a–n) that are copied from `SendMessageRequestHeader` on every send. With `FastCodesHeader` support in `SendMessageRequestHeader` (#10535), the V1 header can directly produce the V2 wire format, eliminating the per-request object allocation and field-copy overhead. **Suggested approach:** 1. Add V2-compatible `encode(ByteBuf)` / `decode(ByteBuf)` methods to `SendMessageRequestHeader` that use the short field names. 2. Update client-side send paths (`MQClientAPIImpl.sendMessage`) to use `SendMessageRequestHeader` directly with the V2 request code. 3. Deprecate (not remove) `SendMessageRequestHeaderV2` to maintain backward compatibility for any external consumers. --- *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]
