RockteMQ-AI commented on issue #11156: URL: https://github.com/apache/rocketmq/issues/11156#issuecomment-5647025383
**Issue Evaluation** Category: `type/bug` | Status: **Confirmed** The reported issue has been verified against the current codebase on the `develop` branch. **Root Cause:** In `Timeline.TimelineRollService.run()`, the scan window is `[rollCheckpoint + rollRangeHour, rollCheckpoint + rollRangeHour + timerMaxDelaySec]`. With the default `timerMaxDelaySec = 3 days` (259,200s) and a 1-hour roll interval, consecutive scan windows overlap by ~72 hours. This means the same not-yet-expired timer messages remain within the scan range and get rolled repeatedly (~72 times each). Additionally, the roll checkpoint is computed as `System.currentTimeMillis()` each cycle with no persistence. A broker restart would re-scan from the current time, potentially re-rolling messages that were already processed. **Impact:** - Unnecessary RocksDB scan I/O and CPU usage (each message rolled ~72x) - Potential duplicate delivery of scheduled/timer messages - Performance degradation under high timer message volume **Severity:** High — affects data correctness (duplicate delivery) and resource efficiency **Proposed Fix Direction:** The reporter's suggestion to use a persisted RocksDB checkpoint (`timeline_roll_checkpoint`) is sound: 1. Each round scans `[checkpoint, checkpoint + interval)` 2. After successful scan, advance and persist the checkpoint 3. Next due time = `checkpoint + interval - timerMaxDelaySec` (trigger 1s early, poll with ≤1s wait) 4. If behind, scan next window immediately to avoid gaps An automated fix proposal may be generated. Reply `/approve` to proceed with PR generation. --- *Automated evaluation by github-manager-bot* -- 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]
