JackieTien97 commented on code in PR #17631:
URL: https://github.com/apache/iotdb/pull/17631#discussion_r3214496091


##########
iotdb-core/datanode/src/main/java/org/apache/iotdb/db/protocol/client/ConfigNodeClient.java:
##########
@@ -265,6 +265,13 @@ public ConfigNodeClient(
   }
 
   public void connect(TEndPoint endpoint, int timeoutMs) throws TException {
+    // Close old transport to avoid leaking TCP connections on the server side.
+    // Without this, redirect scenarios (Follower -> Leader) overwrite the 
transport
+    // field and leave the old connection open, causing server-side RPC 
threads to
+    // block indefinitely on the abandoned socket.

Review Comment:
   Nit: This 4-line comment is somewhat verbose for what is essentially a 
defensive `close()` before reassignment. The full context (redirect scenario, 
server-side thread leak) is already well-documented in the commit message and 
PR description. Consider trimming to a single line, e.g.:
   
   ```java
   // Close existing transport before reassigning to prevent connection leaks.
   ```
   
   The code itself (`if (transport != null) { transport.close(); }` before a 
field reassignment) is a well-known resource-management pattern that most Java 
developers will recognize on sight.



##########
iotdb-core/datanode/src/main/java/org/apache/iotdb/db/protocol/client/ConfigNodeClient.java:
##########
@@ -265,6 +265,13 @@ public ConfigNodeClient(
   }
 
   public void connect(TEndPoint endpoint, int timeoutMs) throws TException {
+    // Close old transport to avoid leaking TCP connections on the server side.
+    // Without this, redirect scenarios (Follower -> Leader) overwrite the 
transport
+    // field and leave the old connection open, causing server-side RPC 
threads to
+    // block indefinitely on the abandoned socket.
+    if (transport != null) {

Review Comment:
   Now that `connect()` always closes the old transport before creating a new 
one, the existing `transport.close()` in `tryToConnect()` (lines 337-339 on 
master, lines 344-346 in this PR) becomes redundant — when the round-robin loop 
calls `connect(tryEndpoint, timeoutMs)`, the old transport will be closed at 
entry.
   
   The duplicate close is *harmless* (`TTransport.close()` is idempotent), but 
having two call sites that both claim responsibility for transport cleanup is a 
maintenance hazard. It's ambiguous whether `tryToConnect()` or `connect()` owns 
the lifecycle.
   
   Suggestion: remove the `if (transport != null) { transport.close(); }` block 
in `tryToConnect()` so that `connect()` is the single owner of transport 
teardown. This makes the contract clearer: **every** `connect()` call manages 
its own cleanup.



-- 
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]

Reply via email to