[SERVER-21218] mongos getMore command implementation does not forward maxTimeMS to the shards Created: 30/Oct/15  Updated: 17/Nov/15  Resolved: 05/Nov/15

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: 3.2.0-rc1
Fix Version/s: 3.2.0-rc3

Type: Bug Priority: Major - P3
Reporter: Jeffrey Yemin Assignee: David Storch
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:
  • 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 })

Sprint: QuInt C (11/23/15)
Participants:

 Description   

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.



 Comments   
Comment by Githook User [ 05/Nov/15 ]

Author:

{u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}

Message: SERVER-21218 make mongos forward maxTimeMS on getMore command to mongod
Branch: master
https://github.com/mongodb/mongo/commit/5b34689a84b969affc822e014e44816959ca460b

Comment by David Storch [ 30/Oct/15 ]

jeff.yemin, you're right, I misunderstood the problem. I thought you were saying that the problem is that the getMore command does not return a "time limit expired" error. You are correct that mongod is using the default awaitData timeout of 1 second rather than the user-supplied maxTimeMS. This is happening since mongos is not forwarding the maxTimeMS to the shards.

Comment by Jeffrey Yemin [ 30/Oct/15 ]

I think it does have something to do with mongos. My tests pass on standalone and replica sets.

Comment by David Storch [ 30/Oct/15 ]

SERVER-19410 is about adding functionality to mongos such that mongos enforces the maxTimeMS timeout in addition to the shards. This is about a case in which neither the shards nor mongos are returning a "time limit exceeded error", so I do not think it is a dup. Re-opening.

Also, I don't think this has anything to do with mongos. A standalone mongod server should exhibit the same behavior.

Comment by Scott Hernandez (Inactive) [ 30/Oct/15 ]

dup of SERVER-19410

Generated at Thu Feb 08 03:56:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.