-
Type:
Improvement
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Workload Resilience
-
Fully Compatible
-
v8.3
-
Workload Resilience 2026-04-13
-
200
-
None
-
None
-
None
-
None
-
None
-
None
-
None
In SPM-4003, behavior was introduced to the connection pool to force a refresh of the next returned connection after an establishment failed in a non-empty pool instead of clearing the pool. The idea was that the refresh would determine if all connections in the pool were dead or if the one failure was isolated (primarily due to it being rate limited by the remote).
However, "refreshing" a connection first checks if the pool's connection count is above minPoolSize + length of the queue, and if so closes the connection instead. This aggressive check is normally only performed when a connection is being refreshed due to being idle (1m by default), which is quite rare. The effect is that the pool will cull its idle connections when being faced with rate limiter errors, and in the worst case eventually clearing the pool since there were no idle connections left.
To fix this in the immediate term, we should just drop the forced refresh requirement. This will ensure the pool doesn't clear itself in response to establishment rate limiting while avoiding the extra culling.
- related to
-
SERVER-123391 ConnectionPool always logs that connection setup fails
-
- Closed
-