• Type: Icon: Sub-task Sub-task
    • Resolution: Fixed
    • Priority: Icon: Unknown Unknown
    • 4.13.0
    • Affects Version/s: None
    • Component/s: None
    • 0
    • Not Needed
    • Not Needed

      Monitor Updates

      • No changes necessary.

      Topology

      • When we reset the pool, we will check if it’s a network timeout error and pass the result into Pool.clear().

       

      {{const interruptInUseConnections = error instanceof MongoNetworkTimeoutError;
      pool.clear(interruptInUseconnections)}}

      Connection Pool

      • Pool.clear() now takes a boolean indicating whether or not we should close checked out connections
        • unknown: Pool.clear currently takes an optional ObjectId property.  Adding a second optional property will result in optional argument handling.  Is converting `clear` to take an options object okay?
      • Pool.clear() will iterate over each checked out connection and close it, passing in a retryable network error. The error should be a PoolClearedError with the following message: "Connection to <pool address> interrupted due to server monitor timeout". I lean towards option 2.
        • Option 1: create a PoolClearedError and manually attach the retryable read and retryaable write labels
        • Option 2: subclass PoolClearedError (PoolClearedOnNetworkTimeoutError) and make this error retryable, and fail with this error.
      • The pool MUST only interrupt in-use Connections whose generation is less than or equal to the generation of the pool at the moment of the clear (before the increment) that used the interruptInUseConnections flag.
      • According to the spec, killing the connections should happen on the “same background thread” as minPoolSize population. I think the better approach is to have a standalone task kill in progress operations manually.
        • Is there a potential race condition if I do this asynchronously?
        • No, because if an in-flight operation succeeds between the time at which the monitor check fails (and we schedule the cleanup task) and the actual cleanup task runs, the connection will be checked back into the pool, and the cleanup task will not find this connection in the set of checked out connections.

      Connection Class

      • Enhance DestroyOptions to take an optional error, which will get passed down into the call to distroy. Pass this error into any calls to connection.destroy but not connection.end.

       

      Unskip all spec tests skipped in step 2.

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

              Created:
              Updated:
              Resolved: