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

Cursor may indicate that it is not exhausted even though next getMore will close the cursor and return no results

    XMLWordPrintable

Details

    • Bug
    • Status: Backlog
    • Major - P3
    • Resolution: Unresolved
    • 3.1.6
    • None
    • Querying
    • ALL
    • Hide

      use test
      db.foo.insert({_id: 1})
      db.foo.insert({_id: 2})
      db.foo.insert({_id: 3})
       
      db.foo.find({_id: {$gt: 1}}).limit(2)
      

      Show
      use test db.foo.insert({_id: 1}) db.foo.insert({_id: 2}) db.foo.insert({_id: 3})   db.foo.find({_id: {$gt: 1}}).limit(2)

    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

          Activity

            People

              backlog-query-execution Backlog - Query Execution
              craig.wilson@mongodb.com Craig Wilson
              Votes:
              0 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

                Created:
                Updated: