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

// Increase logLevel so that the logs indicate when a getMore occurs.
db.adminCommand({setParameter: 1, logLevel: 1});
 
t = db.t;
t.drop();
db.createCollection("t", {capped: true, size: 2048});
t.insert({a: 1});
 
var cursor = t.find().addOption(DBQuery.Option.tailable).limit(-3);
cursor.next();
 
t.insert({a: 1});
cursor.next(); // This triggers a getMore, but it should not.



 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.

Generated at Thu Feb 08 03:45:07 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.