[SERVER-29858] allow Shard::exhaustiveFindOnConfig to run on shards as well, and rename to Shard::exhaustiveFind Created: 26/Jun/17  Updated: 23/Feb/18  Resolved: 23/Feb/18

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

Type: Task Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Esha Maharishi (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-29859 replace plumbing of ShardRemote::exha... Closed
Participants:

 Description   

For the first time, the config server needs to run a command (listCollections) against a shard that returns a cursor.

The alternatives are to use DBClient::query or link establishCursors() and the ARM/ClusterClientCursor onto mongod, which is an entire summer 2017 intern project.

We should replace the plumbing of ShardRemote::exhaustiveFind with establishCursors/ARM once they are linked into mongod, so that we can do a clean replace of the Fetcher with those with one change.



 Comments   
Comment by Esha Maharishi (Inactive) [ 23/Feb/18 ]

Eh... I think I filed this when moving shardCollection to the config server (shardCollection calls listCollections against the shard being added), because I wanted to update this listCollections call from using legacy networking to ASIO.

The only options we had were

  • make Shard::exhaustiveFindOnConfig, which can run cursor-generating commands over ASIO, runnable on shards
  • use establishCursors/ARM

I ended up doing neither and just left it as using legacy networking from the config server, as seen in 3.7.2.

So, yeah, closing as Won't Fix until we have a reason to attempt it again.

Comment by Gregory McKeon (Inactive) [ 23/Feb/18 ]

esha.maharishi is this still necessary?

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