RockteMQ-AI commented on issue #10911: URL: https://github.com/apache/rocketmq/issues/10911#issuecomment-5267879508
**Issue Evaluation** Category: `bug` | Status: **Confirmed — Needs Deep Investigation** Thank you for the thorough forensic analysis. The evidence strongly suggests a real corruption issue in the Broker remoting receive/decode path: - BODYCRC match confirms corruption happened before write - Cross-connection frame embedding rules out disk corruption - Concurrent decoder errors on independent connections during the incident second **Assessment:** This is a serious data integrity issue. The analysis points to a potential ByteBuf lifecycle / ownership problem in the Netty codec pipeline, possibly related to pooled buffer reuse when `serverPooledByteBufAllocatorEnable=true`. **Note:** The issue is reported on branch 4.9.8 with Netty 4.1.65.Final. The current `develop` branch uses a newer Netty version, so the first step would be to verify whether the issue still exists on the latest codebase. **Recommended next steps:** 1. Verify reproducibility on the latest `develop` branch 2. Audit the `RemotingCommand.decode()` path for ByteBuf ownership assumptions 3. Check if the `DefaultEventExecutorGroup` in the codec pipeline could cause cross-thread buffer access 4. Consider adding a defensive copy in the decode path if pooled buffers are shared across pipeline stages This issue warrants maintainer attention. An automated investigation of the decode path on the current `develop` branch can be initiated if desired. --- *Automated evaluation by github-manager* -- 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]
