[SERVER-46986] Add read_timeout setting for the client Created: 19/Mar/20  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: 4.2.3
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Georgy Savva Assignee: Backlog - Service Architecture
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Assigned Teams:
Service Arch
Participants:

 Description   

The documentation says that I should always set maxTimeMS for operations that use "linearizable" read concern:
https://docs.mongodb.com/manual/reference/read-concern-linearizable/#performance-comparisons

db.restaurants.find( { _id: 5 } ).readConcern("linearizable").maxTimeMS(10000)

Otherwise my query will block indefinitely in case the majority of the nodes are unavailable, because the Primary node needs to check with majority of nodes that it's still the Primary.
Originally, maxTimeMS setting purpose is to limit time that query takes to process on the server, and it seems that,  it also covering this case with majority of nodes unavailable too, what is a network issue actually. So as I understand, it works the same way as wtimeout setting for write operations.
The only difference is that I can specify wtimeout as a part of the write concern globally for my client via the connection URI. Or even on the server in replication configuration.
And it's not the case for the maxTimeMS, because I need to add it to every query.
It's very inconvenient when I need my database to be highly consistent and "linearizable" is my default read concern level for the client and I specify it in my connection URI.
I believe that we should have global read_timeout setting for the client and configure it via the connection URI as we do with wtimeout.

 



 Comments   
Comment by Lauren Lewis (Inactive) [ 21/Dec/21 ]

We haven’t heard back from you in at least 1 year, so I'm going to close this ticket. If this is still an issue for you, please provide additional information and we will reopen the ticket.

Comment by A. Jesse Jiryu Davis [ 13/Apr/20 ]

Hello, we are planning a project this year to create one operation timeout to rule them all. It will behave the same in all drivers and the shell, and it will supersede many of our existing timeouts. Instead of adding a specific read_timeout setting like you propose, we plan for the shell to implement the same universal timeout as the one we design for drivers.

Comment by Carl Champain (Inactive) [ 19/Mar/20 ]

Hi georgy.savva@gmail.com,

Thank you for the report.
We are passing this ticket along to the appropriate team for further investigation. Updates will be posted as they happen.

Kind regards,
Carl
 

Generated at Thu Feb 08 05:12:58 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.