wang-jiahua opened a new pull request, #10975:
URL: https://github.com/apache/rocketmq/pull/10975
### Which Issue(s) This PR Fixes
Fixes #10973
### Brief Description
Every POP response and every ACK goes through `ExtraInfoUtil`. Two
allocation sources removed without touching the wire format:
1. `parseStartOffsetInfo` / `parseMsgOffsetInfo` / `parseOrderCountInfo`
used `split` per entry (a `String[]` plus three substrings), then
re-concatenated the first two fields into a map key; `parseMsgOffsetInfo` split
the offset list again with `split(",")`. Entries are now walked with `indexOf`
and the map key is built with `StringBuilder.append(CharSequence, int, int)`,
so the arrays and most substrings are gone (the value keeps one substring for
`parseLong`; the Java 8 target has no range-parse API).
2. `getCkQueueOffset` / `getPopTime` / `getInvisibleTime` returned boxed
`Long` although every caller in the repository assigns the result straight to a
`long`. They now return `long`.
Notes for reviewers:
- The getter change is source-compatible for all in-repo callers (none rely
on nullability or identity) but binary-incompatible for externally compiled
bytecode, which needs a recompile against the new remoting artifact.
- The previous split-based validation half-accepted corrupt entries with
empty fields or trailing separators (producing keys like `"@a"`); the new
validation rejects them with the same `IllegalArgumentException` used for other
malformed shapes. Builder-produced wire strings are unaffected, covered by new
round-trip tests.
### How Did You Test This Change?
- `ExtraInfoUtilTest` extended with round-trip (normal + retry topic,
multi-entry), getter, and malformed-input cases, 5/5 pass;
`AckMessageProcessorTest` / `ChangeInvisibleTimeProcessorTest` /
`PopMessageProcessorTest` 25/25; `MQClientAPIImplTest` 133/133.
- 4-node cluster A/B in POP mode (`mqadmin setConsumeMode -m POP`, producer
64 threads + consumer 20 threads, consume TPS steady at 150-154k, pop path
confirmed active via pop.log, 3 interleaved trials per side):
- broker side (remoting jar swapped on the broker): young GC per million
consumed msgs 2.60/2.62/2.70 (base) vs 2.63/2.64/2.62 (patch) — parity;
- client side (remoting jar swapped on the consumer): 1.10/1.08/1.10 vs
1.11/1.10/1.10 — parity.
No regression on either side; the allocation saving itself (tens of bytes
per response) is below GC-count resolution, so this is a cleanup-level
optimization on a hot path plus stricter rejection of corrupt extraInfo input.
--
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]
