Uploaded image for project: 'Drivers'
  1. Drivers
  2. DRIVERS-2750

Clarify connection checkout timeout when timeoutMS is enabled

    • Type: Icon: Spec Change Spec Change
    • Resolution: Unresolved
    • Priority: Icon: Unknown Unknown
    • None
    • Component/s: CSOT
    • Needed
    • Hide

      Summary of necessary driver changes

      •  

      Commits for syncing spec/prose tests
      (and/or refer to an existing language POC if needed)

      •  

      Context for other referenced/linked tickets

      •  
      Show
      Summary of necessary driver changes   Commits for syncing spec/prose tests (and/or refer to an existing language POC if needed)   Context for other referenced/linked tickets  

      Summary

      As specified, CSOT calculates a timeout for server selection and connection checkout.  The timeout for server selection is the min(timeoutMS, serverSelectionTimeoutMS).  The timeout calculated for connection checkout is currently defined as the remaining timeout calculated for server selection.  Consequently, when CSOT is enabled, serverSelectionTimeoutMS applies to both server selection and connection checkout.

      There was discussion in the CSOT channel that came to the conclusion that

      • Go and Python both missed this requirement in their implementation
      • This behavior is unexpected and surprising to users and can lead to an increase in timeouts
      • If we want a single timeout to govern both server selection and connection checkout, https://jira.mongodb.org/browse/DRIVERS-1262 is a preferable solution

      The spec should be updated to state that the timeout for connection checkout is the remaining timeoutMS.

      See the Server Selection section of the CSOT spec for details.

      Motivation

      Who is the affected end user?

      Drivers engineers implementing CSOT, users who may see increased connection checkout timeout behavior when CSOT is enabled.

      How does this affect the end user?

      Users might see an increase in connection checkout timeouts.  For retryable reads/writes, these should be retried so long as their is sufficient timeoutMS remaining but for non-retryable operations, users might see an increase in timeouts.  These timeouts would be confusing because depending on the value of `serverSelectionTimeoutMS` and `timeoutMS`, an operation can fail before `timeoutMS` has expired.

      How likely is it that this problem or use case will occur?

      Unsure.  Go and Python haven't implemented the logic as written in the spec.

      If the problem does occur, what are the consequences and how severe are they?

      There is the possibility of an increased number of timeouts / connection checkout failures.

      Is this issue urgent?

      Yes, we want this clarified as soon as possible.

      Is this ticket required by a downstream team?

      no.

      Is this ticket only for tests?

      no.

      Acceptance Criteria

      • Clarify the intended timeout for connection checkout.

            Assignee:
            Unassigned Unassigned
            Reporter:
            bailey.pearson@mongodb.com Bailey Pearson
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: