Add Centralized bufio.Reader to topology.connection

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • None
    • Go Drivers
    • None
    • None
    • None
    • None
    • None
    • None

      Context

      The driver's internal topology.connection logic should be refactored to include a persistant bufio.Reader. There motivation for this is to safely use peek. More specifically, GODRIVER-3173 will, under certain conditions, require performing an aliveness check before attempting to drain the buffer on a TCP connection that previously failed due to a socket timeout. Currently there is no way to do that without discarding bytes from the TCP buffer, which can cause problems with subsequently reading the size.

      Definition of done

      1. Add a single br *bufio.Reader field to the topology.connection struct
      2. Initialize this reader exactly once within the connect() method, immediately after the underlying net.Conn (nc) is fully established (post-TLS handshake)
      3. Refactor all methods that read from the connection, specificially read() and awaitPendingResponse(), to use the shared conn.br
      4. Add a test for the custom dialer case--for example users will expect a 2 part read: one for the size and one for the rest of the message. Likely the size check will still need to use c.nc since c.br will by default try to do a large internal fill (e.g. 4096).

      This change centralizes all read operations through a single, long-lived buffered reader, ensuring data integrity and optimizing network performance.

      Pitfalls

      bufio.Reader is not safe for concurrent use, this design relies on the assumption that the connection pol realizes access given to a connection object. While this is a spec-requirement, if there is any flaw in the pool's locking or checkout logic that allows two goroutines to read from the same connection simultaneously, it will lead to mangled data and likely difficult-to-diagnose race conditions.

            Assignee:
            Preston Vasquez
            Reporter:
            Preston Vasquez
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: