Don't request refresh of next returned connection in response to establishment failure

XMLWordPrintableJSON

    • Type: Improvement
    • Resolution: Fixed
    • Priority: Major - P3
    • 9.0.0-rc0
    • 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.

            Assignee:
            Patrick Freed
            Reporter:
            Patrick Freed
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: