[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: |
|
||||||||
| 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
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? |