[SERVER-58938] Update DBClientCursor::_postBatchResumeToken when running an aggregate command and pass it to the callback function in RSLocalClient::runAggregation Created: 28/Jul/21 Updated: 06/Dec/22 Resolved: 01/Dec/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Janna Golden | Assignee: | [DO NOT USE] Backlog - Sharding NYC |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | PM-234, PM-234-M3, PM-234-T-oplog-fetch, sharding-nyc-subteam1 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Sharding NYC
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Story Points: | 3 | ||||||||||||||||
| Description |
|
Currently we don't set _postBatchResumeToken on DBClientCursor for an aggregate command. We should, and then should pass it to the callback function in RSLocalClient::runAggregation to allow a resharding recipient that is fetching from itself (because it's also a donor) to resume more efficiently. |
| Comments |
| Comment by Max Hirschhorn [ 01/Dec/21 ] |
|
Confirmed with Kal that ShardLocal is used only by the config server locally to talk to itself. |
| Comment by Max Hirschhorn [ 18/Nov/21 ] |
We should write this JavaScript test first because based on the state of a core dump I was debugging in BF-23392, it seems like replica set shards will use ShardRemote even for their own shard name. Perhaps ShardLocal is only a special case on the config server replica set? |
| Comment by Max Hirschhorn [ 08/Nov/21 ] |
|
Acceptance criteria:
|