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

Tailable cursor fails on getMore against a sharded cluster

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical - P2
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.6.8, 4.0.0-rc0
    • Component/s: Querying, Sharding
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v3.6
    • Sprint:
      Query 2018-04-23, Query 2018-05-07

      Description

      A getMore command on tailable cursor fails against a sharded cluster with error code 50737 and the error message

      Cannot run getMore on cursor 64893492584, which was created in session 3ef6563a-9883-4ba8-8fa2-d42cca34030b - 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=, without an lsid'.

      The sequence of commands and responses were:

      { "find" : "test", "filter" : { }, "tailable" : true, "awaitData" : true, "$db" : "test", "$clusterTime" : { "clusterTime" : { "$timestamp" : { "t" : 1522368868, "i" : 1 } }, "signature" : { "hash" : { "$binary" : "AAAAAAAAAAAAAAAAAAAAAAAAAAA=", "$type" : "00" }, "keyId" : { "$numberLong" : "0" } } }, "lsid" : { "id" : { "$binary" : "PvZWOpiDS6iPotQsyjQDCw==", "$type" : "04" } } }
      { "cursor" : { "firstBatch" : [{ "_id" : { "$oid" : "5abd7f7b8ed66ff6dbf0dd10" } }, { "_id" : { "$oid" : "5abd7f988ed66ff6dbf0dd11" } }], "id" : { "$numberLong" : "6209935563551417631" }, "ns" : "test.test" }, "ok" : 1.0, "$clusterTime" : { "clusterTime" : { "$timestamp" : { "t" : 1522368868, "i" : 1 } }, "signature" : { "hash" : { "$binary" : "AAAAAAAAAAAAAAAAAAAAAAAAAAA=", "$type" : "00" }, "keyId" : { "$numberLong" : "0" } } }, "operationTime" : { "$timestamp" : { "t" : 1522368865, "i" : 1 } } }
       
      { "getMore" : { "$numberLong" : "6209935563551417631" }, "collection" : "test", "$db" : "test", "$clusterTime" : { "clusterTime" : { "$timestamp" : { "t" : 1522368868, "i" : 1 } }, "signature" : { "hash" : { "$binary" : "AAAAAAAAAAAAAAAAAAAAAAAAAAA=", "$type" : "00" }, "keyId" : { "$numberLong" : "0" } } }, "lsid" : { "id" : { "$binary" : "PvZWOpiDS6iPotQsyjQDCw==", "$type" : "04" } } }
      { "cursor" : { "id" : { "$numberLong" : "6209935563551417631" }, "ns" : "test.test", "nextBatch" : [] }, "ok" : 1.0, "$clusterTime" : { "clusterTime" : { "$timestamp" : { "t" : 1522368870, "i" : 1 } }, "signature" : { "hash" : { "$binary" : "AAAAAAAAAAAAAAAAAAAAAAAAAAA=", "$type" : "00" }, "keyId" : { "$numberLong" : "0" } } }, "operationTime" : { "$timestamp" : { "t" : 1522368870, "i" : 1 } } }
       
      { "getMore" : { "$numberLong" : "6209935563551417631" }, "collection" : "test", "$db" : "test", "$clusterTime" : { "clusterTime" : { "$timestamp" : { "t" : 1522368870, "i" : 1 } }, "signature" : { "hash" : { "$binary" : "AAAAAAAAAAAAAAAAAAAAAAAAAAA=", "$type" : "00" }, "keyId" : { "$numberLong" : "0" } } }, "lsid" : { "id" : { "$binary" : "PvZWOpiDS6iPotQsyjQDCw==", "$type" : "04" } } }
      

      In some cases it fails on the second getMore, in some cases the third, but otherwise the behavior appears consistent.

      The collection is capped with otherwise default values. In particular, the collection itself is not sharded (not even sure you can created a sharded capped collection...)

      You can see from the commands that the query executes in a session.

      Reproduced on a sharded cluster with two shards (each a single member replica set) with MongoDB Enterprise version 3.7.3-198-g8f75de8 on OS X, but it started appearing in Evergreen some time after 2/19.

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: