zmuxuny opened a new issue, #5555: URL: https://github.com/apache/rocketmq-dashboard/issues/5555
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `master` branch, or I have stated the exact version I am running below. ### Studio Version Originally traced on `rocketmq-studio@0228dad5`. Current fix #5255 was refreshed and validated on 2026-10-04 against `rocketmq-studio@6a68042fa73a513f40436ca721944b4de48181ec`. ### Runtime Environment Apache RocketMQ proxy-connected consumer diagnostics through `ProxyConsumerResolver`. The focused controlled startup-failure and concurrent-first-use regressions run under Java 21 with mocked remoting clients. ### Connected RocketMQ Cluster Apache RocketMQ through Proxy remoting. A live cluster is not needed for the controlled resolver startup/retry regressions; the original report did not depend on a particular broker version or deployment. ### Build Toolchain Java 21 and Maven for the focused resolver regressions. This is remoting-client initialization at runtime; commands and current validation limitations are recorded in #5255. ### Describe the Bug `ProxyConsumerResolver.remotingClient()` publishes `clientStarted=true` with `compareAndSet(false, true)` before calling `NettyRemotingClient.start()`. If the first start throws, the same client and true flag remain cached. Later proxy queries skip startup and use a client that never completed initialization. A second caller can also see the flag while the first startup is still running and call `invokeSync` before the client is ready. ### Steps to Reproduce Startup failure/retry: 1. Arrange for the first remoting client's `start()` to throw a transient startup exception. 2. Trigger a proxy-connected consumer diagnostic lookup. 3. Clear the transient failure and trigger another lookup. 4. Observe whether a fresh client is started or the failed client is reused. Concurrent first use: 1. Hold the first client's `start()` pending. 2. Trigger a second proxy query while startup is still in progress. 3. Check whether the second query calls `invokeSync` before startup completes. Both interleavings follow from setting the ready flag before `start()` returns. ### What Did You Expect to See? Publish a reusable remoting client only after startup succeeds. Concurrent first-use calls should wait for startup. A failed first startup should allow the next request to initialize a fresh client. Keep normal shutdown limited to the successfully started client and clean up failed startup candidates. Cover failure/retry and concurrent-first-use paths with controlled tests. ### What Did You See Instead? After startup throws, `remotingClient` still references the failed client and `clientStarted` remains true. Later lookups skip `start()` and can keep reporting proxy connection information as unavailable even after the transient problem clears. Concurrent callers can invoke the client while its first startup is still incomplete. ### Additional Context This replaces the previous report [#5057](https://github.com/apache/rocketmq-dashboard/issues/5057), automatically closed by the stale bot on 2026-10-04. That closure was an inactivity action, not a maintainer rejection of the report or fix. Current fix: [#5255](https://github.com/apache/rocketmq-dashboard/pull/5255), which remains open. It publishes the client only after startup succeeds and retries with a fresh client after failure. The former #5058 submission and the 2026-09-26 report of 89 focused Java tests passing are historical. Fresh 2026-10-04 validation and remaining CI limitations are recorded in #5255; overall CI is not green. Searched open issues for `ProxyConsumerResolver` and the previous report reference. #5128 concerns cached Proxy addresses after instance endpoint changes; #2807 concerns transient proxy-address discovery failure. Neither covers remoting-client startup or first-use publication. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- 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]
