[SERVER-50424] Make resharding refresh retryable and asynchronous Created: 20/Aug/20 Updated: 27/Oct/23 Resolved: 29/Jul/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Haley Connelly | Assignee: | Max Hirschhorn |
| Resolution: | Gone away | Votes: | 0 |
| Labels: | PM-234-M3, PM-234-O-unspecialized, PM-234-T-lifecycle | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Sprint: | Service Arch 2021-06-28, Service Arch 2021-07-12 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Story Points: | 3 | ||||||||||||||||||||
| Description |
|
SERVER-49567 introduces a resharding refresh mechanism. Once SERVER-50371 and SERVER-50342 are complete, the refresh mechanism should be retryable until are shards successfully refresh or one returns a non-retryable error. |
| Comments |
| Comment by Max Hirschhorn [ 29/Jul/21 ] |
|
sharding_util::sendCommandToShards() isn't fully async but its usage in the ReshardingCoordinator has been made retryable through the use of resharding::WithAutomaticRetry() from |
| Comment by Blake Oler [ 10/Nov/20 ] |
|
From talking with matthew.saltz – a quick version of this ticket just mimics the following code. But the depended ticket is meant to create a higher-level helper that will forgo the necessity for a "needs-retryable block" to have to write in its own retry. |
| Comment by Blake Oler [ 10/Nov/20 ] |
|
A note – if you dig down the dependency chain, this ticket ultimately relies on the implementation of cancelation tokens (PM-1423). |