[SERVER-17636] tailable cursors should obey negative ntoreturn Created: 17/Mar/15 Updated: 06/Dec/22 Resolved: 02/Aug/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 2.6.8, 3.0.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | David Storch | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | query-44-grooming | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query
|
| Operating System: | ALL |
| Participants: |
| Description |
|
For regular (non-tailable) cursors, a negative ntoreturn value instructs the server to generate at most one batch of results. After generating the first batch, the server is expected to close the cursor and pass a cursorid of 0 back to the client. The server ignores that the ntoreturn value is negative for tailable cursors, and is willing to send multiple batches of results (i.e. at least one getMore) back to the client. You can reproduce this behavior with the script below:
|
| Comments |
| Comment by David Storch [ 02/Aug/19 ] |
|
The ntoreturn parameter is specific to the legacy OP_QUERY read protocol. It has been superseded by the find command. Instead of noreturn, the find command accepts separate batchSize and limit options, neither of which can be negative. We do not currently plan to schedule special work to improve the implementation of legacy OP_QUERY reads. Closing this ticket as Won't Do. |
| Comment by David Storch [ 17/Mar/15 ] |
|
We could also consider making the combination of tailable and negative ntoreturn an error, as it doesn't make much sense to use these options in combination. |