[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: |
|
||||||||||||||||
| 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: |
| 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. |