3219378872 opened a new issue, #11228: URL: https://github.com/apache/rocketmq/issues/11228
### Before Creating the Bug Report - [x] This is a defect in the Proxy Admin implementation in this repository. - [x] I searched open and closed issues/PRs for `ProxyAdminForwarder`, admin forwarding and deadlines. The implementation introduced by #10826 is present; I found no existing fix for this path. ### Runtime platform environment Ubuntu 24.04 / WSL2, x86_64. Reproduced with a real loopback Netty gRPC peer and the production `ProxyAdminForwarder`, using a stubbed consumer directory to route a remote client. No running broker is needed for this forwarding-path reproduction. ### RocketMQ version `develop` at `78b96bc5e21216cd7896efae08f90c5cde4cae53`, including the pinned `rocketmq-apis` submodule at `3e60073c6dab3430feaec443824802e23ecda681`. ### JDK Version Temurin 8u504-b01, Maven 3.9.9. ### Describe the Bug `ProxyAdminForwarder.invokeOnPeer` takes a cached `AdminGrpc.AdminStub`, attaches metadata and invokes the peer without setting a deadline. If the caller does not supply a gRPC deadline, the outgoing call has none. A peer that accepts the call but never responds can retain the forwarded request indefinitely, even though the proxy has `grpcAdminServerRequestTimeoutMillis` configured. This affects the client-directed admin RPCs forwarded to the owning proxy: `GetConsumerRunningInfo`, `PrintThreadStackTrace` and `VerifyMessage`. Local broker/telemetry timeouts do not bound a stalled network hop to the peer. ### Steps to Reproduce 1. Enable Proxy Admin and set its request timeout (the regression fixture uses 1000 ms). 2. Register a remote client in the consumer directory, pointing to a loopback peer running the normal `Admin` gRPC service. 3. Have that peer accept `GetConsumerRunningInfo` but return no response. 4. Call `forwardIfRemote` without an incoming deadline and inspect the peer's gRPC context. The peer receives **no deadline**. In the new regression test, the baseline fails: ```text Tests run: 2, Failures: 1, Errors: 0, Skipped: 0 java.lang.AssertionError: the peer call must carry the configured deadline ``` The shorter-caller-deadline control passes on the baseline, confirming that propagation works when the caller supplies one; it is the proxy's own bound that is missing. ### What Did You Expect to See? Apply a fresh configured timeout to each forwarded call. An unresponsive peer should terminate with `DEADLINE_EXCEEDED`; a shorter incoming deadline should still win. The cached channel/stub must remain usable for subsequent calls after an earlier call times out. ### Proposed fix and validation Set `withDeadlineAfter(grpcAdminServerRequestTimeoutMillis, MILLISECONDS)` on the per-invocation stub, document that the existing setting also bounds the peer-proxy hop, and add real-transport regression tests for the stalled peer, cached-channel reuse and shorter incoming deadline. The reproduction is scoped to forwarding and cancellation; it is not a full multi-proxy/broker deployment benchmark. I am preparing the fix and tests with AI assistance and will include the exact validation commands in the PR. -- 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]
