zjncs opened a new pull request, #11117:
URL: https://github.com/apache/rocketmq/pull/11117
## Motivation
`AdminBrokerProcessor.queryConsumeTimeSpan` (backing `mqadmin
queryConsumeTimeSpan` and the console's consume-time-span view) computes
per-queue timestamps with two unguarded lookups:
```java
long maxTime =
this.brokerController.getMessageStore().getMessageStoreTimeStamp(topic, i, max
- 1);
...
if (consumerOffset < maxBrokerOffset) {
long nextTime = ... getMessageStoreTimeStamp(topic, i, consumerOffset);
timeSpan.setDelayTime(System.currentTimeMillis() - nextTime);
}
```
- **Empty queue:** `max == 0`, so the first lookup queries offset `-1`; the
store answers `-1` and `maxTimeStamp` is reported as `-1`, which clients render
as an epoch timestamp (1970/1969) for a queue that simply has no messages.
`getTopicStatsInfo` already guards the identical lookup with `if (max > 0)` and
defaults to `0`.
- **Group never committed:** `ConsumerOffsetManager.queryOffset` returns
`-1` for an unknown group/queue, so `consumerOffset(-1) < maxBrokerOffset(0)`
holds even for an empty queue; `nextTime` is `-1` and `delayTime` becomes `now
- (-1)` — i.e. the current epoch in milliseconds, shown as an absurd delay.
## Modification
- Guard the max-timestamp lookup with `if (max > 0)`, defaulting to `0`,
exactly like `getTopicStatsInfo`.
- Compute `delayTime` only when `consumerOffset >= 0 && consumerOffset <
maxBrokerOffset`, so a group with no committed offset gets `0` instead of
epoch-based garbage.
## Test Evidence
**Fail-before** (unpatched code, new test
`AdminBrokerProcessorTest#testQueryConsumeTimeSpanEmptyQueueReportsZeroMaxTimestamp`
— topic with default queues, empty store, group with no committed offset):
```
docker exec rmq-build mvn -q -pl broker test
-Dtest='AdminBrokerProcessorTest#testQueryConsumeTimeSpanEmptyQueueReportsZeroMaxTimestamp'
-Dsurefire.failIfNoSpecifiedTests=true
Tests run: 1, Failures: 1 ... expected: 0L
```
With only the max-timestamp guard applied, the test's `verify(never())`
further exposed the delayTime path still calling
`getMessageStoreTimeStamp(topic, i, -1)` with `consumerOffset == -1`
(`NeverWantedButInvoked`), which motivated the second guard.
**Pass-after** (full class with both guards):
```
docker exec rmq-build mvn -q -pl broker test
-Dtest='AdminBrokerProcessorTest' -Dsurefire.failIfNoSpecifiedTests=true
Tests run: 94, Failures: 0, Errors: 0, Skipped: 0
```
No associated issue (self-discovered during a broker-module self-audit).
--
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]
