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

mongos getMore command implementation does not forward maxTimeMS to the shards

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • 3.2.0-rc3
    • Affects Version/s: 3.2.0-rc1
    • Component/s: Querying
    • None
    • Fully Compatible
    • ALL
    • Hide
      • Create a sharded cluster
      > db.runCommand({create : 'capped', capped : true, size : 1000})
      { "ok" : 1 }
      > db.capped.insert({})
      WriteResult({ "nInserted" : 1 })
      > db.runCommand({ find : "capped", tailable : true, awaitData : true } )
      {
      	"waitedMS" : NumberLong(0),
      	"cursor" : {
      		"id" : NumberLong("55252308213"),
      		"ns" : "test.capped",
      		"firstBatch" : [
      			{
      				"_id" : ObjectId("5633601e75e5b938982f0ad3")
      			}
      		]
      	},
      	"ok" : 1
      }
      
      // Expected to return in about 1000 seconds, but instead returns in about 1.
      > db.runCommand({ getMore : NumberLong("55252308213"), collection : "capped", maxTimeMS : 1000000 })
      
      Show
      Create a sharded cluster > db.runCommand({create : 'capped', capped : true, size : 1000}) { "ok" : 1 } > db.capped.insert({}) WriteResult({ "nInserted" : 1 }) > db.runCommand({ find : "capped", tailable : true, awaitData : true } ) { "waitedMS" : NumberLong(0), "cursor" : { "id" : NumberLong("55252308213"), "ns" : "test.capped", "firstBatch" : [ { "_id" : ObjectId("5633601e75e5b938982f0ad3") } ] }, "ok" : 1 } // Expected to return in about 1000 seconds, but instead returns in about 1. > db.runCommand({ getMore : NumberLong("55252308213"), collection : "capped", maxTimeMS : 1000000 })
    • QuInt C (11/23/15)

      Mongod should respect maxTimeMS on getMore commands for cursors that are tailable + awaitData, but it does not.

      Expected result: getMore command replies after maxTimeMS expires

      Actual result: getMore command replies after 1 second, which is the server's default , rather than blocking for a 1000 second timeout.

            Assignee:
            david.storch@mongodb.com David Storch
            Reporter:
            jeff.yemin@mongodb.com Jeffrey Yemin
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: