[ISSUE #10538] Eliminate SendMessageRequestHeaderV2 intermediate object in client

[wang-jiahua]

Client creates SendMessageRequestHeaderV2 per send with 14 field copies. With #10535 FastCodesHeader, SendMessageRequestHeader can encode V2 directly, making the intermediate object unnecessary.

[RockteMQ-AI]

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

[salmaloel657-dotcom]

I agree with the assessment regarding ISSUE #10538. Since FastCodesHeader now allows SendMessageRequestHeader to encode V2 directly, eliminating the SendMessageRequestHeaderV2 intermediate object is a logical step to reduce overhead. The suggested approach to add V2-compatible methods to SendMessageRequestHeader and update the client-side send paths while deprecating the old header seems sound. I will begin looking into the implementation in MQClientAPIImpl and SendMessageRequestHeader.

…

On Mon, Jun 22, 2026, 5:03 AM RockteMQ-AI ***@***.***> wrote: *RockteMQ-AI* left a comment (apache/rocketmq#10538) <#10538 (comment)> *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 <#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* — Reply to this email directly, view it on GitHub <#10538?email_source=notifications&email_token=CABFFMOR3Q5QO2WW7AW4X5L5BD763A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZWG4YTCNZUHA22M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4767117485>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CABFFMMO5RNVCUJPDU2C4WD5BD763AVCNFSNUABEKJSXA33TNF2G64TZHM3TKMJWGQ4DEMZ3JFZXG5LFHM2DOMJVGUYDCNRUG6QXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CABFFMODECPEJT5ID6Y6ANT5BD763A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZWG4YTCNZUHA22M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CABFFMPFTCLSXJMHFPV6AQ35BD763A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZWG4YTCNZUHA22M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[RockteMQ-AI]

Issue Evaluation

Category: type/enhancement | Status: Evaluated

Feasibility: Feasible
Scope: client module — MQClientAPIImpl and SendMessageRequestHeaderV2
Compatibility: Backward compatible — the V1 header path remains for older brokers.

Eliminating the intermediate SendMessageRequestHeaderV2 object on the hot path is a valid micro-optimization. The current flow (V1 → V2 → Properties) creates unnecessary allocations per message. Caching the V2→Properties conversion for unchanged fields would reduce GC pressure in high-throughput scenarios.

This is a good first contribution for someone familiar with the client send path.

---

Automated evaluation by RockteMQ-AI