Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-36105

Implement server support for exhaust cursors in OP_MSG

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.1.3
    • Component/s: Querying
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Sprint:
      Repl 2018-07-30, Repl 2018-08-13, Repl 2018-08-27
    • Linked BF Score:
      0

      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.

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                9 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: