Details
-
Bug
-
Resolution: Unresolved
-
Major - P3
-
None
-
3.1.6
-
Query Execution
-
ALL
-
Description
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.
Attachments
Issue Links
- 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
-