CRZbulabula opened a new pull request, #17631: URL: https://github.com/apache/iotdb/pull/17631
## Summary - Fix a TCP connection leak in `ConfigNodeClient.connect()` on the DataNode side: when a DataNode is redirected from a Follower ConfigNode to the Leader, the old transport is not closed before being overwritten, causing server-side `TThreadPoolServer` worker threads to block indefinitely on abandoned sockets - This was observed in a 5C20D cluster during ConfigNode failover testing — after two ConfigNodes were restarted, the former leader accumulated 55 leaked `ConfigNodeRPC-Processor` threads (vs. 1 for a normal follower), all stuck in `SocketDispatcher.read0` waiting on connections that would never receive data ## Root Cause In `ConfigNodeClient.tryToConnect()`, when `configLeader` is set (redirect scenario), the code calls `connect(configLeader)` which directly overwrites `this.transport` with a new connection. The old transport to the previous ConfigNode is never closed. The server-side `TThreadPoolServer` keeps the corresponding worker thread alive, blocking on the now-orphaned socket. The leak path: 1. DataNode borrows `ConfigNodeClient` from pool, already connected to ConfigNode A (Follower) 2. RPC returns `REDIRECTION_RECOMMEND` → `configLeader` is set to ConfigNode B (Leader) 3. Retry loop calls `connectAndSync()` → `tryToConnect()` → `connect(B)` 4. `connect()` overwrites `transport` with a new connection to B; old transport to A is leaked 5. ConfigNode A's `TThreadPoolServer` worker thread blocks forever on the abandoned socket ## Fix Close the existing transport at the beginning of `connect()` before creating a new one. This covers all call paths (redirect branch and round-robin fallback loop in `tryToConnect()`). ## Test Plan - [ ] `mvn compile -pl iotdb-core/datanode` passes - [ ] Verify in a multi-ConfigNode cluster: after leader failover and redirect, the old Follower's `ConfigNodeRPC-Processor` thread count stays at normal levels (1 for idle followers) instead of accumulating leaked threads -- 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]
