[SERVER-12619] parallelCollectionScan not honoring numCursors Created: 05/Feb/14  Updated: 10/Dec/14  Resolved: 05/Feb/14

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: 2.5.5
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Christian Amor Kvalheim Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-12310 create parallelCollectionScan Closed
Operating System: ALL
Steps To Reproduce:

use t
for(var i = 0; i < 10000; i++) db.t.insert({a:i})
db.runCommand({parallelCollectionScan: 't', numCursors:6})

Results in

{
	"cursors" : [
		{
			"cursor" : {
				"firstBatch" : [ ],
				"ns" : "t.t",
				"id" : NumberLong("100109016162")
			},
			"ok" : true
		},
		{
			"cursor" : {
				"firstBatch" : [ ],
				"ns" : "t.t",
				"id" : NumberLong("100764228900")
			},
			"ok" : true
		},
		{
			"cursor" : {
				"firstBatch" : [ ],
				"ns" : "t.t",
				"id" : NumberLong("98906230722")
			},
			"ok" : true
		},
		{
			"cursor" : {
				"firstBatch" : [ ],
				"ns" : "t.t",
				"id" : NumberLong("100039922834")
			},
			"ok" : true
		}
	],
	"ok" : 1
}

Participants:

 Description   

Might be a documentation issue or bug but not sure. it does seem numCursors is the "upper" bound of cursors used instead of the fixed number of cursors returned.



 Comments   
Comment by Eliot Horowitz (Inactive) [ 05/Feb/14 ]

It is an upper bound.

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