GerardGao opened a new pull request, #16436: URL: https://github.com/apache/dubbo/pull/16436
## What changed `AbstractNettyConnectionClient.scheduleReconnect` now delegates the blocking `doConnect()` to the client executor instead of running it inline on the framework-shared connectivity scheduler thread. ## Why `doConnect()` blocks on the connecting promise for up to the connect timeout (3s by default). When several providers are unreachable, each failed connection occupied one of the shared scheduler's `availableProcessors` threads for the full timeout, starving the reconnect tasks of all other clients. Healthy connections then experienced request timeouts even though the server responded quickly (apache/dubbo#13853). The shared scheduler now only handles the delay; the blocking connect runs on the per-client executor, so one client's reconnects can no longer starve the others. ## Testing - Added `ScheduleReconnectTest` which stubs `performConnect` with a never-completing promise and asserts the reconnect attempt runs on a `DubboClientHandler` thread rather than the shared scheduler thread. The test fails on the previous implementation and passes with the fix. - `mvn -pl dubbo-remoting/dubbo-remoting-netty4 test -Dtest=ScheduleReconnectTest,SingleProtocolConnectionManagerTest,MultiplexProtocolConnectionManagerTest,NettyPortUnificationServerHandlerTest` passes (6/6). - `spotless:check` and `checkstyle:check` pass. Fixes #13853 -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
