zmuxuny opened a new issue, #5057: URL: https://github.com/apache/rocketmq-dashboard/issues/5057
### Before creating the bug report - [x] Searched open issues and PRs for `ProxyConsumerResolver` remoting-client startup/retry. #2807 addresses transient proxy-address discovery failure, not client startup. - [x] Traced the current `rocketmq-studio@0228dad5` initialization path; a focused regression will follow. ### Studio version and runtime `rocketmq-studio@0228dad5`, Apache RocketMQ proxy-connected consumer diagnostics through `ProxyConsumerResolver`. ### Problem and reproduction `ProxyConsumerResolver.remotingClient()` publishes `clientStarted=true` with `compareAndSet(false, true)` before it calls `NettyRemotingClient.start()`. If that first start throws, the same client remains in `remotingClient` and the flag remains true. Later proxy queries skip `start()` entirely and use the client that did not complete initialization. The current resolver catches these query errors and can keep reporting proxy connection information as unavailable, even after the transient startup problem has cleared. A second caller can also observe `clientStarted=true` while the first caller's `start()` is still running and call `invokeSync` on a client that is not yet ready. Both interleavings follow from the current flag order. ### Expected behavior Publish a reusable remoting client only after startup succeeds. Concurrent first-use calls should wait for that startup, and a failed first startup should leave the resolver able to initialize a fresh client on the next request. Keep shutdown limited to a successfully started client and cover the startup-failure/retry and concurrent-first-use paths with controlled tests. -- 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]
