[SERVER-38727] Add command parameter to specify max wait time for speculative majority reads Created: 20/Dec/18  Updated: 29/Oct/23  Resolved: 23/Jan/19

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.1.8

Type: Task Priority: Major - P3
Reporter: William Schultz (Inactive) Assignee: Backlog - Replication Team
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Related
related to SERVER-34277 Add 'maxAwaitTimeMs' parameter to get... Backlog
related to SERVER-37560 Allow change streams to work with spe... Closed
Assigned Teams:
Replication
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.0, v3.6
Participants:

 Description   

We would like to add a new command argument that specifies how long a client is willing to wait for data to become majority committed when doing a speculative majority read. This is primarily to work around the fact that getMore commands on tailable, awaitData cursors do not use maxTimeMS as a global command timeout. They instead use it as the amount of time to wait for new inserts before returning to the client. Since speculative majority waiting may happen after batch generation, there is no way currently to specify a time limit on speculative majority waiting in this case. The goal is to address this issue with a new parameter; something analogous to the wtimeout parameter of write concern.



 Comments   
Comment by Githook User [ 23/Jan/19 ]

Author:

{'username': 'will62794', 'email': 'william.schultz@mongodb.com', 'name': 'William Schultz'}

Message: SERVER-38727 Remove TODO and update comment about speculative majority read timeout
Branch: master
https://github.com/mongodb/mongo/commit/c5daf6b72b4cba76d08e6cb5354883ceef340d18

Comment by William Schultz (Inactive) [ 14/Jan/19 ]

In accordance with the final resolution decided upon in WRITING-3469, we will simply leave the hard-coded timeout value that currently exists in the server. This ticket should then only involve cleaning up the comment and TODO in the code.

Comment by William Schultz (Inactive) [ 20/Dec/18 ]

This ticket is partially a placeholder for a discussion we need to have (and perhaps mini-design or scope) around the behavior of maxTimeMS for getMore on tailable, awaitData cursors. Currently the maxTimeMS parameter defines how to long to wait for new data to arrive, but doesn't act as a global command timeout. As mentioned above, this is problematic for speculative majority reads. One solution is to give maxTimeMS on getMores the same meaning it has for all other commands, and add a new parameter that controls how long to wait for new data. SERVER-34277 touches on this issue.

Comment by Andy Schwerin [ 20/Dec/18 ]

This is a user facing feature, and may involve drivers changes. We'd be committing to having this for a long time, but my inclination has been to eliminate wtimeout in favor of more intelligent error reporting when maxtimems expires.

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