-
Type: Improvement
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Component/s: None
-
None
The ServiceStateMachine will implement the server side of the exhaust cursor OP_MSG protocol.
- After receiving a getMore command and running command processing, the ServiceStateMachine will check the reply message before sending it to the client.
- If the result has an error, or a cursor ID of 0 or an empty namespace, or either of those fields does not exist or is corrupt, the reply message will be sent normally without the moreToCome bit set.
- If the result is OK and has both valid cursor ID and namespace, the reply message will be sent with the moreToCome bit set. The ServiceStateMachine will synthesize an OP_MSG with a getMore the same as the original getMore it was sent (including the exhaustAllowed bit), only with an ID the same as the ID of the reply. This will result in getMore command processing being run again, and another reply being sent to the client. This reply will appear to be a reply to the previous reply.
Example: client sends a getMore with cursorId 9 for collection “mydb.mycoll” with 3 documents:
opCode: OP_MSG requestId: 1 responseTo: 0 (not used for messages from client) flagBits: exhaustAllowed body: { getMore: 9, batchSize: 2 }
Server sends first response:
opCode: OP_MSG requestId: 1001 responseTo: 1 flagBits: moreToCome body: { ok: 1, cursor: {id: 9, ns: “mydb.mycoll”} } documentSequence: [doc1, doc2]
Since there are more documents, the server runs the getMore again and sends the response:
opCode: OP_MSG requestId: 1002 responseTo: 1001 flagBits: 0 body: { ok: 1, cursor: {id: 0, ns: “mydb.mycoll”} } documentSequence: [doc3]
Because the cursor was exhausted, the moreToCome flag was not set and the cursor ID was 0.
- depends on
-
SERVER-36105 Implement server support for exhaust cursors in OP_MSG
- Closed
- duplicates
-
DRIVERS-535 Support Exhaust Cursor in OP_MSG
- Development Complete