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

Support for the waitQueueTimeoutMS connection parameter

    XMLWordPrintableJSON

Details

    • Icon: Improvement Improvement
    • Resolution: Works as Designed
    • Icon: Unknown Unknown
    • None
    • None
    • None
    • None
    • 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?

    Description

      It appears that the `waitQueueTimeoutMS` connection string parameter isn't supported by the Go driver yet. I thought it was because it's listed as an option on this page: https://www.mongodb.com/docs/drivers/go/current/faq/#how-does-connection-pooling-work-in-the-go-driver-

      I've tested this behaviour using 1.11.1 against MongoDB 5.0 by adding `waitQueueTimeoutMS=1&maxPoolSize=1` to my connection string and then adding lots of load on an endpoint that performs queries. What I saw was requests queueing up quickly and waiting for a long time until I stopped the test at which point they slowly recovered.

      Here's a visual representation of the "sawtooth" pattern that I saw during the test:

      This pattern is also what we're seeing in our production environment during traffic spikes. Requests are hanging for many seconds, sometimes minutes.

      Would it be possible to implement the `waitQueueTimeoutMS`, so waiting on a connection pool acquisition could be aborted quickly? Ideally, this would generate a PoolEvent, so we could track occurrences of this situation in our metrics.

      I found this old comment: https://jira.mongodb.org/browse/GODRIVER-211?focusedCommentId=1791246&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1791246 . In case it's still the reason why this connection string parameter isn't supported I'd like to offer a use case where that explanation isn't sufficient. In our case, we have some occasional long-running queries that are using the same client instance that's handling most of our traffic and making only quick queries. If we were to use a timeout on the context or on the client itself we would either cause the longer-running queries to fail unnecessarily (with a small timeout) or for goroutines to wait much longer than our users would when the connection pool is exhausted (with a long timeout). The `waitQueueTimeoutMS` option enables quick load shedding while allowing for longer timeouts under low-load conditions. In general, we would like queries to run for as long as they need to if there're enough connections available in the pool, but fail quickly if the pool is exhausted. Is there another way of accomplishing this without the `waitQueueTimeoutMS` option?

      Attachments

        Activity

          People

            preston.vasquez@mongodb.com Preston Vasquez
            dv@glyphy.com D V
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: