btlqql opened a new pull request, #7142:
URL: https://github.com/apache/rocketmq-dashboard/pull/7142
## What is the purpose of the change
`InstanceService.loadCounts` started the consumer-group lookup
unconditionally after the topic lookup. A batch that has already reached its
deadline or been cancelled interrupts its worker, but a provider that ignores
the interrupt can still return the first count afterwards — so the worker went
on to start the second provider lookup for a response nobody was waiting for
(`InstanceService.java:202`).
`loadCounts` now checks the worker's interrupt flag between the two lookups
and throws `InterruptedException` while it is still set. The exception takes
the runner's existing failure path (`InstanceResourceCountRunner.execute` →
`CompletedCount.failure`), so there is no executor-policy change: the caller
keeps its existing unavailable response and a healthy batch still performs both
lookups. `Thread.interrupted()` consumes the flag the way any
`InterruptedException` producer does, so the pooled worker does not inherit a
stale interrupt for its next count task.
The pre-existing late-result test
`timedOutCountTaskShouldNotMutateReturnedInstanceAfterRequestCompletesTest`
signalled its "provider finished" latch from `countGroups`, i.e. it required
the second lookup to be reached. It now signals that latch when the first
lookup returns, so it still proves response isolation without depending on the
unwanted call. This does not detect an interrupt a provider cleared itself, and
it does not stop I/O that is already in flight.
## Brief changelog
-
`server/src/main/java/org/apache/rocketmq/studio/instance/InstanceService.java`:
`loadCounts` declares `throws InterruptedException` and fails between the two
lookups when the worker is still interrupted, so the consumer-group lookup is
not admitted; the runner's existing failure path handles the exception.
-
`server/src/test/java/org/apache/rocketmq/studio/instance/InstanceServiceTest.java`:
new latch-controlled regression
`cancelledCountBatchShouldNotStartTheGroupLookupTest`, and the existing
late-result test no longer waits for the consumer-group lookup to signal
completion.
## Verifying this change
- red: `mvn -o -B -ntp test
-Dtest='InstanceServiceTest#cancelledCountBatchShouldNotStartTheGroupLookupTest'`
on the unmodified production code → `Tests run: 1, Failures: 1` with
`NeverWantedButInvoked: instanceProvider.countGroups("slow")` — `But invoked
here: at InstanceService.loadCounts(InstanceService.java:202)`
- green: the same command after the fix → `Tests run: 1, Failures: 0,
Errors: 0`
- regressions run: `mvn -o -B -ntp test
-Dtest='InstanceServiceTest,InstanceResourceCountRunnerTest'` → `Tests run:
106, Failures: 0, Errors: 0`
- not run: the full backend suite, CI, and any live vendor SDK. The
cancellation cases use latch-controlled `InstanceProvider` mocks, so this is
not evidence that a real running I/O call can be forcibly stopped.
## Checklist
- [x] one issue, one PR: Fixes #7077
- [x] regression test added
- [x] targeted suites re-run
--
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]
