[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:
Related
related to PYTHON-908 Document serverSelectionTimeoutMS. Cl... Closed

 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 PYTHON-908 for a related discussion.



 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:

  • connectTimeoutMS – this option controls how long the driver will wait during server monitoring when opening a connection to a server or checking a server's status before concluding the server is unavailable
  • serverSelectionTimeoutMS – this option controls how long the driver will wait to find an available, appropriate server to carry out a database operation; while it is waiting, multiple server monitoring operations may be carried out, each controlled by connectTimeoutMS
  • socketTimeoutMS – this option controls how long the driver will wait for a response after sending an ordinary (non-monitoring) database operation before concluding that a network error has occurred
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 ]

For multi-threaded drivers, no big deal. For single-threaded, crucial.

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 ]

https://github.com/mongodb/specifications/blob/master/source/server-discovery-and-monitoring/server-discovery-and-monitoring.rst#socket-timeout-for-monitoring-is-connecttimeoutms

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:

  • Connect timeout – used both for connecting to servers and for SDAM isMaster() calls; this can be set short so things fail fast when network connections go down.
  • Socket timeout – this can be long, like maxTimeMS; this is how long to wait for regular operations to return a response after they are sent before concluding that the network is down rather than just that the server is slow.

Put differently: use "connect timeout" for "are you up-or-down" questions, but use "socket timeout" for "are you still thinking?" questions.

Generated at Thu Feb 08 08:21:02 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.