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

Tailable cursor fails on getMore against a sharded cluster

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Critical - P2 Critical - P2
    • 3.6.8, 4.0.0-rc0
    • Affects Version/s: None
    • Component/s: Querying, Sharding
    • None
    • Fully Compatible
    • ALL
    • v3.6
    • Query 2018-04-23, Query 2018-05-07

      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.

            Assignee:
            charlie.swanson@mongodb.com Charlie Swanson
            Reporter:
            jeff.yemin@mongodb.com Jeffrey Yemin
            Votes:
            0 Vote for this issue
            Watchers:
            13 Start watching this issue

              Created:
              Updated:
              Resolved: