When a tailable cursor is used in combination with a batch size B, the semantics should be:
- The initial find should return up to B results, without waiting for at least B. That is, if B = 4, but there were only 3 matching documents, it should return just those 3.
- A getMore against a tailable cursor should return an empty batch if there are no further results.
- A getMore against a tailable cursor with N < B new results should return N without waiting for a full B to appear to fill the batch.
- A getMore against a tailable cursor with N >= B new results should return B, and return the rest on the next getMore (subject to the same batch size constraints).
If using a tailable cursor against a mongod process, these are the semantics. However, if running against a mongos (which you can do with an unsharded capped collection), the last case breaks down a bit. The mongos correctly returns batches up to size B, but messes up the next getMore, incorrectly 'remembering' that the next result on that cursor should be EOF (see reproduction steps for more details).
Specifically, the boolean '_eofNext' tracked within the AsyncResultsMerger is not reset on each getMore, so a full batch on one getMore will cause an empty batch on the next, even if there are more results to return.
- is depended on by
-
SERVER-29142 Add sharding support for targeting a single shard when requesting $changeNotifications on an unsharded collection or database.
- Closed