waterWang opened a new pull request, #10967:
URL: https://github.com/apache/rocketmq/pull/10967
### What
Fixes #10966 — the `TransactionalOpBatchService` thread busy-loops at ~100%
CPU after a transaction-message workload goes idle.
### Root cause
`deleteContext` entries are only ever `putIfAbsent` in
`deletePrepareMessage()` and never removed. Once a context has been fully
drained (all offsets batched and sent), it stays in the map forever with a
**stale `lastWriteTimestamp`**.
In `batchSendOpMessage()`, when every context is empty, the scan falls
through to the stale-`firstTimestamp` branch:
- `firstTimestamp = min(startTime, staleLastWrite)` → stale value
- `wakeupTimestamp = stale + interval < startTime` → the `wakeupTimestamp >
startTime` guard fails
- method returns `0L`
Back in `TransactionalOpBatchService.run()`:
```java
long interval = wakeupTimestamp - System.currentTimeMillis(); // 0 - now < 0
if (interval <= 0) { interval = 0; wakeup(); }
this.waitForRunning(interval); // waitForRunning(0) returns immediately
```
→ tight loop, one CPU core pinned at ~100% indefinitely.
### Fix
When no op message was batched in the round (`sendMap == null`), return
`System.currentTimeMillis() + transactionOpBatchInterval` instead of `0L`, so
the thread sleeps until the next scheduled scan. New deletes still wake it
promptly via `deletePrepareMessage() -> transactionalOpBatchService.wakeup()`.
### Verification
- New regression test
`testBatchSendOpMessage_noPendingDataReturnsFutureWakeup` — places a drained
context (stale `lastWriteTimestamp = 0`) in `deleteContext` and asserts the
returned wakeup time is in the future.
- `mvn -am -pl broker test -Dtest=TransactionalMessageServiceImplTest` →
**Tests run: 9, Failures: 0, Errors: 0** (8 pre-existing + 1 new).
- Standalone loop simulation of `TransactionalOpBatchService.run()` +
`batchSendOpMessage()`: before fix **12,126,584 iterations/2s** (busy loop),
after fix **13 iterations/2s** (sleeps normally).
--
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]
