[DRIVERS-222] Deprecate connectTimeoutMS? Created: 21/Apr/15 Updated: 17/Mar/20 Resolved: 04/Oct/16 |
|
| Status: | Closed |
| Project: | Drivers |
| Component/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Bernie Hackett | Assignee: | David Golden |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
A number of drivers support the connectTimeoutMS URI option. The introduction of serverSelectionTimeoutMS seems to make this far less of a useful user facing option. We still need a select timeout for making an initial socket.connect() call, but from a driver behavior perspective serverSelectionTimeoutMS will always appear to dominate (at least for multi-threaded languages). Should we deprecate connectTimeoutMS? See |
| Comments |
| Comment by Rathi Gnanasekaran [ 04/Oct/16 ] |
|
Closing the ticket because we decided not to deprecate connectTimeoutMS option. |
| Comment by A. Jesse Jiryu Davis [ 21/Apr/15 ] |
|
That's great David. |
| Comment by David Golden [ 21/Apr/15 ] |
|
How about:
|
| Comment by Bernie Hackett [ 21/Apr/15 ] |
|
Perhaps what we need here is standard documentation for these two options (connectTimeoutMS and serverSelectionTimeoutMS)? |
| Comment by David Golden [ 21/Apr/15 ] |
I think it applies for multi-threaded drivers, too. Shorter connectTimeout (if used for select with isMaster) means down servers are detected more quickly and thus the topology view is updated more quickly, which means fewer ops possibly routed to a down server. |
| Comment by A. Jesse Jiryu Davis [ 21/Apr/15 ] |
| Comment by David Golden [ 21/Apr/15 ] |
|
Let's imagine my replica set is entirely within a single data center. I might want a really short connectTimeout so that I detect problems quickly. On the other hand, imagine my replica set is 50 hosts spread across the world. I need a longer connectTimeout so that I don't give up talking to servers on the other side of the planet. So I don't think we can pick a default for connection timeouts and then snap off the knob. serverSelectTimeout sits on top and covers the timeout across possibly multiple connection/ismaster attempts and needs to be a multiple of connectTimeout to allow multiple attempts before giving up. serverSectionTimeout is the thing that will affect end-user perceived delay the most, but connectTimeout still affects the latency of the underlying SDAM activities and thus needs to be separately tunable. |
| Comment by A. Jesse Jiryu Davis [ 21/Apr/15 ] |
|
They actually hint drivers about two things. selection timeout is, "how much queueing do I have room for in my application?" connect timeout is, "how fast is my network?" the point of connect timeout is to hint the driver, which never knows whether a server is unresponsive because it's slow or because it's down, that I've set up my network and I believe a server that doesn't respond in 5 sec is probably down. For multi-threaded drivers, no big deal. For single-threaded, crucial. |
| Comment by James Blackburn [ 21/Apr/15 ] |
|
Personally I can reason about connectTimeout vs socketTimeout, and when I might want to do either. ServerSelectTimeout is another axis of configuration that, to me, should be semantically equivalent to connectTimeout. I don't think the user should want to, or be encourage to tune both. In naming terms connectTimeoutMS is semantically clearer than serverSelectionTimeoutMS. Can the driver abstract away this complexity such that tuning the connectTimeoutMS does the right-thing? |
| Comment by Bernie Hackett [ 21/Apr/15 ] |
|
This isn't about connectTimeoutMS vs. socketTimeoutMS though. This is about serverSelectionTimeoutMS, which will always dominate connectTimeoutMS from a users perspective, especially in multi-threaded drivers that use a thread per server for monitoring. |
| Comment by David Golden [ 21/Apr/15 ] |
|
I think we still want both:
Put differently: use "connect timeout" for "are you up-or-down" questions, but use "socket timeout" for "are you still thinking?" questions. |