wang-jiahua opened a new pull request, #10981: URL: https://github.com/apache/rocketmq/pull/10981
### Which Issue(s) This PR Fixes Fixes #10980 ### Brief Description Every POP checkpoint/ack written to the revive topic was serialized as `JSON.toJSONString(x).getBytes(UTF_8)` — a full intermediate `String` plus a second `byte[]` copy per record — and `PopReviveService#scanReviveQueue` materialized `new String(body)` before parsing each CK/ack/batch-ack record. This PR switches the six encode sites (`PopMessageProcessor#buildCkMsg`, `PopBufferMergeService#putAckToStore`/`putBatchAckToStore`, `AckMessageProcessor`, `ChangeInvisibleTimeProcessor` ack + re-put CK) to `JSON.toJSONBytes(x)` and parses revive records straight from `messageExt.getBody()`; the raw string is now built only inside the `enablePopLog` branch that logs it. The stored bytes are unchanged — fastjson2's `toJSONBytes` produces the same UTF-8 bytes as `toJSONString().getBytes(UTF_8)` — and the newer popkv implementation (`PopConsumerRecord`) already uses exactly this pattern. ### How Did You Test This Change? - New byte-equivalence and byte-array round-trip tests (including non-ASCII field values): `PopCheckPointTest` (new), plus new cases in `AckMsgTest` / `BatchAckMsgTest` — 5/5 pass. - Single-class clean runs of the touched broker tests: `AckMessageProcessorTest` 8/8, `ChangeInvisibleTimeProcessorTest` 9/9, `PopMessageProcessorTest` 8/8, `PopBufferMergeServiceTest` 4/4. `PopReviveServiceTest` matches the develop baseline exactly (one pre-existing failure — a V1/V2 retry-topic naming assertion — identical with and without this change). - 4-node cluster A/B in POP mode (`mqadmin setConsumeMode -m POP`, producer 64 threads + consumer 20 threads, consume TPS steady at ~150k, pop path confirmed active via pop.log, per arm clean store + broker restart + page cache drop, 3 interleaved trials, broker jar swapped per arm): broker young GC per million consumed messages 2.67/2.68/2.66 (base) vs 2.66/2.63/2.79 (patch) — parity, zero failures, no regression. The saving itself (one string + one array copy per CK/ack) is below GC-count resolution at this load, so this is a cleanup-level optimization aligned with the popkv precedent. -- 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]
