[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:
Depends
depends on SERVER-50342 Make version of Shard::runCommand tha... Open
depends on SERVER-50341 Make generic whenAll, whenAny, collec... Closed
Related
related to SERVER-49567 Create refresh mechanism to refresh a... Closed
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 SERVER-50937.

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).

Generated at Thu Feb 08 05:22:37 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.