[SERVER-34277] Add 'maxAwaitTimeMs' parameter to getMore command, deprecate usage of 'maxTimeMS' with getMore Created: 03/Apr/18 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Trivial - P5 |
| Reporter: | Charlie Swanson | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | change-streams-improvements | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Query Execution
|
||||||||||||||||
| Backwards Compatibility: | Minor Change | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
The confusion between the generic 'maxTimeMS' argument used for any command and the specific role it plays in a getMore on a tailable, awaitData cursor leads to some unfortunate complexity in the server. The server needs to remember and special-case this argument for getMores. In those cases, the server needs to avoid setting a deadline on the operation to prevent a "fake" timeout, but remember and parse maxTimeMS as a time limit for how long to wait for new inserts. This confusion has lead to many build failures, increased to complexity of development for change streams, and adds some overhead to command processing, although this overhead is probably negligible. |