[DRIVERS-565] Implement server support for exhaust cursors in OP_MSG Created: 21/Aug/18  Updated: 27/May/22  Resolved: 28/Aug/18

Status: Closed
Project: Drivers
Component/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Githook User Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-36105 Implement server support for exhaust ... Closed
Duplicate
duplicates DRIVERS-535 Support Exhaust Cursor in OP_MSG Closed
Server Compat: 4.1

 Description   

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.


Generated at Thu Feb 08 08:21:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.