RockteMQ-AI commented on issue #10911: URL: https://github.com/apache/rocketmq/issues/10911#issuecomment-5262139665
**Issue Evaluation** Category: `bug` | Status: **Confirmed — Needs Investigation** Thank you for the exceptionally detailed report. The evidence you have gathered is compelling: - **BODYCRC match** confirms the corruption occurred before persistence (not a disk or read-tool issue) - **Cross-connection frame embedding** (PULL_MESSAGE frames inside a SEND_MESSAGE body) points to a problem in the Broker's Netty receive/decode pipeline - **Temporal correlation** with `TooLongFrameException` bursts across independent connections strengthens the decode-path hypothesis **Key areas to investigate in the codebase:** 1. `RemotingDecoder` / `NettyDecoder` — whether `cumulator` (ByteToMessageDecoder) can leak or share `ByteBuf` references across connections when `serverPooledByteBufAllocatorEnable=true` 2. `NettyRemotingServer` channel pipeline — whether pooled direct buffers are correctly isolated per-channel under high concurrency with mixed SEND/PULL traffic 3. `Broker2Client` response path — whether callback frames from internal broker-to-broker or broker-to-client paths can bleed into the user-data write path **Severity:** High — silent data corruption in persisted messages is a data integrity issue. **Reproducibility:** Not yet reproduced on unmodified 4.9.8, which makes this harder to triage. The distribution-specific audit you mentioned is important. This warrants a deep code review of the remoting layer, particularly the interaction between pooled ByteBuf allocators and the frame decoder under concurrent heterogeneous traffic. --- *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]
