CritasWang commented on code in PR #62:
URL: 
https://github.com/apache/iotdb-client-csharp/pull/62#discussion_r3688114401


##########
src/Apache.IoTDB/SessionPool.cs:
##########
@@ -172,10 +205,61 @@ protected internal SessionPool(List<string> nodeUrls, 
string username, string pa
             _certificatePath = certificatePath;
             _sqlDialect = sqlDialect;
             _database = database;
+            _poolWaitTimeoutInMs = poolWaitTimeoutInMs;
+        }
+        /// <summary>
+        /// Acquires a client from the pool. If the pool has no idle client 
but owns vacant slots left behind
+        /// by earlier failed reconnections, one of those slots is 
re-materialized on the spot instead of
+        /// blocking on a queue that nobody will ever feed. This is what lets 
the pool recover on its own
+        /// after the server has been unreachable for a while.
+        /// </summary>
+        private async Task<Client> AcquireClientAsync(CancellationToken 
cancellationToken = default)
+        {
+            if (_clients.ClientQueue.IsEmpty && TryReserveVacantSlot())

Review Comment:
   Renamed in 3ad458f: `VacantSlots` → `UnrealizedCapacity`.
   
   "Vacant slots" reads as "something is broken", which is exactly the wrong 
intuition now that refill is documented as demand-driven — a steady non-zero 
value under light load is normal, not a fault. `UnrealizedCapacity` states what 
the number actually measures: configured capacity that has not been 
materialized yet. The private field and `TryReserveVacantSlot` were renamed to 
match, and the metrics table, prose and tests updated.
   
   No compatibility impact — the property is introduced by this PR and has 
never shipped.
   
   I kept the demand-driven behaviour rather than adding eager refill, for the 
reasons above. Happy to revisit if you would still prefer the pool to restore 
full capacity proactively after recovery.



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