Uploaded image for project: 'Go Driver'
  1. Go Driver
  2. GODRIVER-3156

Detect and discard closed connections during check-out

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Unknown Unknown
    • 1.17.1
    • Affects Version/s: None
    • Component/s: CMAP, Connections
    • None
    • Go Drivers
    • Not Needed
    • Hide

      1. What would you like to communicate to the user about this feature?
      2. Would you like the user to see examples of the syntax and/or executable code and its output?
      3. Which versions of the driver/connector does this apply to?

      Show
      1. What would you like to communicate to the user about this feature? 2. Would you like the user to see examples of the syntax and/or executable code and its output? 3. Which versions of the driver/connector does this apply to?

      Context

      Currently the Go driver never attempts to detect connections that were closed by the other side when checking out connections. As a result, it's possible to return a connection that's been closed by the other side where any read or write operations will immediately fail. Instead, we should check if the connection has been closed when checking out a connection.

      Definition of done

      • Check if a connection has been closed when checking out the connection. If it has, discard it and try to return another connection.

      Pitfalls

      Checking if a connection has been closed by the other side isn't as straightforward as calling an IsClosed method on the connection. These are some possible approaches:

      • Make a non-blocking read request for the connection. If an error is returned, the connection is closed.
        • That depends on the ability to call a non-blocking read, which may or may not be practical in Go.
      • Call conn.Read with a very short read deadline. If an error is returned, the connection is closed.
        • We need to make sure conn.Read returns before using the connection to run an operation. Otherwise, there will be concurrent read and write requests, which will lead to undefined behavior.
      • Investigate the APIs available by type-asserting the conn to a *TCPConn, possibly using the underlying file descriptor to figure out its state.
        • It's not clear if that's possible.

            Assignee:
            matt.dale@mongodb.com Matt Dale
            Reporter:
            matt.dale@mongodb.com Matt Dale
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: