wang-jiahua opened a new pull request, #10977:
URL: https://github.com/apache/rocketmq/pull/10977
### Which Issue(s) This PR Fixes
Fixes #10976
### Brief Description
Two per-message allocation sources removed on the proxy gRPC path:
1. `BinaryUtil.calculateMd5` performed a `MessageDigest.getInstance("MD5")`
provider lookup and created a fresh digest on every call;
`GrpcConverter#buildSystemProperties` hits this for every message delivered to
a gRPC consumer. The digest is now kept per thread in a `ThreadLocal`
(`MessageDigest` is not thread safe) and `reset()` before each use.
2. `SendMessageActivity#buildMessageProperty` (and `validateMessageGroup`)
called `getBytes(StandardCharsets.UTF_8)` on every user-property key/value, the
tag, each message key, and the message group, only to read `.length` for size
validation. A new `utf8Length(String)` helper computes the encoded length
without materializing the array, matching `String.getBytes(UTF_8).length`
exactly (including the single-byte replacement for unpaired surrogates); the
five call sites now use it.
### How Did You Test This Change?
- `BinaryUtilTest` (new): result matches a fresh `MessageDigest`, and stays
stable across interleaved calls on the reused per-thread instance.
- `SendMessageActivityTest#testUtf8Length`: sample-by-sample equality with
`getBytes(UTF_8).length` covering ASCII, CJK, supplementary (emoji), and
unpaired surrogates; full class 12/12.
- Dedicated gRPC A/B on a 4-node cluster: proxy in cluster mode plus a
loopback load tool built on `rocketmq-client-java` 5.0.7 (producer 8 threads
with multi-byte user properties exercising `utf8Length`; SimpleConsumer 4
threads exercising the digest path), swapping the proxy's
`rocketmq-common`/`rocketmq-proxy` jars per arm, 3 interleaved trials plus 1
reversed-order control: ~9.4k send TPS / ~5.1k consume TPS with zero failures
in all 8 arms; proxy young GC counts showed a pure positional artifact (first
arm of each pair always 9, second always 10, independent of the jar — confirmed
by the reversed-order control), i.e. parity after correction. No regression;
the allocation saving is below GC-count resolution, so this is a cleanup-level
optimization on the proxy hot path.
--
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]
