[Enhancement] Serialize POP checkpoint/ack messages without the intermediate JSON string

[wang-jiahua]

Before Creating the Enhancement Request

• I have confirmed that this should be classified as an enhancement rather than a bug/feature.

Summary

Serialize POP checkpoint/ack messages with JSON.toJSONBytes and deserialize them with JSON.parseObject(byte[], ...) instead of going through an intermediate JSON String.

Motivation

Every POP checkpoint and ack that reaches the revive topic is serialized as JSON.toJSONString(x).getBytes(UTF_8) — a full String (with its internal array) plus a second byte[] copy per record — in five call sites: PopMessageProcessor#buildCkMsg, PopBufferMergeService#putAckToStore / putBatchAckToStore, AckMessageProcessor, and ChangeInvisibleTimeProcessor (ack + re-put CK). On the read side, PopReviveService#scanReviveQueue first materializes new String(body) and then parses it, for CK, ack, and batch-ack records alike.

The newer popkv implementation already does this directly: PopConsumerRecord uses JSON.toJSONBytes(this) / JSON.parseObject(body, ...).

Solution

• Replace the six encode sites with JSON.toJSONBytes(x).
• Parse 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 writes the same UTF-8 bytes as toJSONString().getBytes(UTF_8). New tests assert byte-for-byte equality (including non-ASCII field values) and byte-array round-trips for PopCheckPoint, AckMsg, and BatchAckMsg.

Verification

• New equivalence/round-trip tests: PopCheckPointTest, 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, 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, 3 interleaved trials, broker jar swapped per arm): broker young GC per million consumed msgs 2.67/2.68/2.66 (base) vs 2.66/2.63/2.79 (patch) — parity, no regression. The saving itself (one string + one copy per CK/ack) is below GC-count resolution at this load; this is a cleanup-level optimization consistent with the popkv precedent.

[RockteMQ-AI]

Issue Evaluation

Category: type/enhancement | Status: Evaluated

Feasibility: Feasible — straightforward cleanup with clear precedent in the existing PopConsumerRecord implementation.

Scope: module/broker — PopMessageProcessor, PopBufferMergeService, AckMessageProcessor, ChangeInvisibleTimeProcessor, PopReviveService.

Compatibility: No breaking changes — fastjson2's toJSONBytes produces identical UTF-8 bytes as toJSONString().getBytes(UTF_8), so the on-wire format is unchanged.

Assessment:

This is a clean, well-verified optimization. The key points:

1. Byte equivalence is correct — fastjson2's toJSONBytes writes the same UTF-8 encoding as toJSONString().getBytes(UTF_8), so stored bytes are wire-compatible. The new tests asserting byte-for-byte equality (including non-ASCII values) provide strong confidence.

2. Allocation savings are real but modest — eliminating one String allocation + one byte[] copy per CK/ack record reduces young-gen pressure on the revive path. At 150k TPS the GC count delta is below resolution, which is expected — the value is consistency with the popkv precedent and reducing unnecessary allocations on hot paths.

3. Five encode sites + three decode sites — the scope is well-contained. The change is mechanical and low-risk.

4. Test coverage is solid — equivalence tests + round-trip tests + single-class clean runs of all touched broker tests. The pre-existing failure in PopReviveServiceTest matching baseline is the right validation approach.

This looks ready for a PR. The approach is sound, the verification is thorough, and the risk is minimal.

---

Automated evaluation by github-manager

[RockteMQ-AI]

Issue Evaluation

Category: enhancement | Status: Evaluated

Feasibility: Feasible
Scope: Performance optimization — no API/protocol changes
Compatibility: Backward compatible

This is a well-scoped performance improvement targeting Serialize POP checkpoint/ack messages without intermediate JSON. The analysis is specific and the proposed change reduces unnecessary allocation/encoding overhead.

This type of incremental optimization is valuable for high-throughput scenarios.

---

Automated evaluation by github-manager