-
Type: Bug
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: 3.1.6
-
Component/s: Querying
-
Query Execution
-
ALL
-
I'm unsure if this is a bug or simply a change, but it needs to be documented or fixed as certain tests drivers are running have started failing.
The gist of this is that when 3.0 exhausted the documents from a query, it didn't return a cursorId. This has changed in 3.1.x where a cursor will be returned even when there are no more documents to iterate. This prompts a driver to issue a kill cursor.
I grabbed the wire bits to make this easier to understand.
MessageLength 95 RequestID XX ResponseTo 0 OpCode OP_QUERY(2004) Flags 0 FullCollectionName test.foo NumberToSkip 0 NumberToReturn 2 Query { $query: { _id: { $gt: 1 } } }
When running against server 3.0.5, the OP_REPLY is the following:
RequestID XX MessageLength 78 ResponseTo XX OpCode OP_REPLY(1) ResponseFlags AwaitCapable(8) CursorID 0 StartingFrom 0 NumberReturned 2 Documents [{ _id: 2, x: 22 },{ _id: 3, x: 33 }]
However, when running against 3.1.7, the OP_REPLY is the following:
RequestID XX MessageLength 78 ResponseTo XX OpCode OP_REPLY(1) ResponseFlags AwaitCapable(8) CursorID 14624793327 StartingFrom 0 NumberReturned 2 Documents [{ _id: 2, x: 22 },{ _id: 3, x: 33 }]
Notice that the CursorID is non-zero in the 3.1 code.
When running this from the shell, the shell does not issue a kill cursor, so if you are looking at the wire from the shell, that won't be there. I'm unsure if that's a bug in the shell or not.
- is duplicated by
-
SERVER-21086 mongos does not kill cursor with getMore command when batch size gets you exactly to the limit
- Closed
- is related to
-
SERVER-17839 Remove PlanStage::isEOF
- Backlog