zjncs opened a new pull request, #11105:
URL: https://github.com/apache/rocketmq/pull/11105
### Motivation
`MQAdminImpl.queryMessage` fans out one asynchronous query per broker and
waits on a `CountDownLatch(brokerAddrs.size())`. The latch is released by the
`InvokeCallback` (`operationSucceed`/`operationFail`), but if
`MQClientAPIImpl.queryMessage` itself throws synchronously — e.g.
`RemotingConnectException`/`RemotingTimeoutException` for an unreachable broker
— no callback is ever invoked, and the catch block only logs:
```java
} catch (Exception e) {
log.warn("queryMessage exception", e);
}
...
boolean ok = countDownLatch.await(timeoutMillis * 4, TimeUnit.MILLISECONDS);
```
The caller then blocks for the full `timeoutMillis * 4` window — **24
seconds** with the default `timeoutMillis` of 6s — before getting the "no
message" answer, even though the outcome was already known. Any tool/admin call
that queries by key while one broker is down pays this stall.
### Modifications
- Add `countDownLatch.countDown();` in the catch block, releasing this
broker's count exactly as the callback would have.
### Verification
Fail-before (new test on unpatched code — the per-broker invoke is mocked to
throw, `timeoutMillis=200`):
```
MQAdminImplTest.assertQueryMessageNotBlockedWhenInvokeThrows:192
queryMessage should not wait for the whole latch timeout, elapsed=846
```
Pass-after — full `MQAdminImplTest` (11 existing + 1 new); the same call now
returns in single-digit milliseconds:
```
mvn -pl client test -Dtest='MQAdminImplTest'
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
```
--
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]
