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