RockteMQ-AI commented on issue #10976:
URL: https://github.com/apache/rocketmq/issues/10976#issuecomment-5437457663
**Issue Evaluation**
Category: `enhancement` | Status: **Evaluated**
**Feasibility:** Feasible
**Scope:** `proxy` module (gRPC send/receive path), `common` module
(`BinaryUtil`, `SendMessageActivity`)
**Compatibility:** No breaking changes — internal optimization only
The two allocation sources are well-identified:
1. **`BinaryUtil.calculateMd5`** — `MessageDigest.getInstance("MD5")` per
call is a provider lookup + fresh instance each time. A
`ThreadLocal<MessageDigest>` with `reset()` is the standard fix and avoids
contention.
2. **`SendMessageActivity` `getBytes(UTF_8)` for length-only** —
materializing byte arrays just to read `.length` creates 2N+ transient objects
per message. A `utf8Length(String)` helper that computes encoded length without
allocation is correct and straightforward.
The proposed verification (gRPC A/B on 4-node cluster, reversed-order
control) is thorough. The observation that allocation savings are below
GC-count resolution is honest — this is a cleanup-level hot-path optimization.
One note: ensure the `ThreadLocal<MessageDigest>` is documented as not
suitable for virtual-thread contexts without adjustment (each virtual thread
gets its own slot).
---
*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]
