[SERVER-20987] Incorrect or missing merge sort in mongos Created: 17/Oct/15  Updated: 20/Mar/16  Resolved: 20/Mar/16

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

Type: Bug Priority: Major - P3
Reporter: Daniel Coupal Assignee: Randolph Tan
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-19355 Support skip, limit, and projection i... Closed
Operating System: ALL
Sprint: Sharding 12 (04/01/16)
Participants:

 Description   

Got an issue from a customer that we were able to reproduce in 2.4, 2.6 and 3.0.

4 clusters return each one document, however a request sorted does not seem to happen in the mongos process.
Note that the field to sort is a sub field in an array, however each document only have one entry in the array.



 Comments   
Comment by David Storch [ 19/Oct/15 ]

I haven't tracked down exactly why this is broken in existing stable versions, but I can confirm that this has been fixed as part of the mongos read path refactor done under SERVER-15176, so this issue will not affect 3.2. In the old mongos query code, mongos would extract the sort key from the result documents and use this for its merge sort. Something in this process appears to be broken.

The new query path instead issues a {$meta: "sortKey"} projection to the shards. (Sort key meta-projection was added in the 3.1 development cycle explicitly for this purpose.) This instructs each shard to return the sort key it generated for each result document as part of its response. Mongos then uses this sort key metadata to perform its mergesort. It then strips out the metadata before returning the result set to the client. This work was done under SERVER-19355.

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