-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Minor - P4
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Execution
-
None
-
None
-
None
-
None
-
None
-
None
-
None
For a sharded cluster, when a find request with a limit equal to batchSize is sent to mongos, the returned cursorid is not 0, like this:
mongos> db.runCommand({find:"coll", limit:1, batchSize:1})
{
"cursor" : {
"firstBatch" : [
{
"_id" : ObjectId("62e38b2509f1b4519551f9d1"),
"a" : 1
}
],
"id" : NumberLong("1810946290033139346"),
"ns" : "mydb.coll"
},
"ok" : 1,
"operationTime" : Timestamp(1659496263, 1),
"$clusterTime" : {
"clusterTime" : Timestamp(1659496269, 2),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}
Then the client will send a getMore request, but get empty data.
From the code of mongos, if the conditions of firstBatch are met, the logic of judging whether clusterClientCursor is EOF will not be entered, so the cursor id will still be brought into the returned result.
code
The second getMore request is unnecessary. Is it possible to make the cursorid returned by the first find request to be 0?
- related to
-
SERVER-108846 Cursors remain open when batchSize equals limit with in-memory sort
-
- Closed
-