[SERVER-68554] For a find request with batchSize equal to the limit size, the mongos of the sharded cluster will return a cursorid not equal to 0, the client will send an extra getMore, and no data is returned Created: 04/Aug/22  Updated: 05/Dec/22

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: Chao Yin Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query Execution
Participants:

 Description   

 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?
 

 



 Comments   
Comment by Steve Tarzia [ 20/Sep/22 ]

1321280378feng@gmail.com thank you for bringing this to our attention and for making an attempt to fix it.  A few of our senior engineers reviewed your PR and we noticed a few deficiencies.  For example, it only addresses the sharded case (not standalone collections) and there is no testing.  I will put this on the backlog for us to consider later.  We don't see this ticket as high priority because it is asking for a minor performance improvement and addressing it would likely complicate our codebase.

Comment by Chao Yin [ 18/Aug/22 ]

Thanks for the quick reply! I've signed the Contributor Agreement.

Comment by Chris Kelly [ 17/Aug/22 ]

Thanks for making this pull request! We just need you to sign our Contributor Agreement as part of our considering the PR.

Comment by Chao Yin [ 17/Aug/22 ]

 I create a PullRequest:  https://github.com/mongodb/mongo/pull/1482.

Comment by Eric Sedor [ 11/Aug/22 ]

Thanks 1321280378feng@gmail.com, I can indeed see that the cursor.id in the find command response is populated given db.runCommand({find:"coll", limit:1, batchSize:1}) but is 0 given db.runCommand({find:"coll", limit:1}). I'll pass this on to an appropriate team to consider.

Generated at Thu Feb 08 06:11:07 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.