[SERVER-50342] Make version of Shard::runCommand that returns a future Created: 17/Aug/20  Updated: 12/Dec/23

Status: Open
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Matthew Saltz (Inactive) Assignee: Backlog - Cluster Scalability
Resolution: Unresolved Votes: 0
Labels: sa-remove-fv-backlog-22, sharding-nyc-subteam2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
depends on SERVER-50658 Add support for CancelationTokens to ... Closed
depends on SERVER-57087 Write unit tests for the AsyncRequest... Backlog
depends on SERVER-57088 Integrate CancelationTokens with the ... Backlog
depends on SERVER-51298 Add cancelation support to AsyncTry/u... Closed
is depended on by SERVER-79125 Change callers of Shard::runCommand t... Backlog
is depended on by SERVER-50424 Make resharding refresh retryable and... Closed
Duplicate
duplicates SERVER-69979 Refactor Shard::runCommand in terms o... Closed
Gantt Dependency
has to be done before SERVER-65892 `Shard::runCommandWithFixedRetryAttem... Backlog
Related
related to SERVER-50371 Make a version of TaskExecutor::sched... Closed
is related to SERVER-69979 Refactor Shard::runCommand in terms o... Closed
is related to SERVER-78557 Allow targeting to wait until there i... Backlog
Assigned Teams:
Cluster Scalability
Sprint: Service Arch 2021-02-22, Service Arch 2021-03-08, Service Arch 2021-03-22, Service Arch 2021-04-05, Service Arch 2021-04-19, Service Arch 2021-05-17, Service Arch 2022-12-26, Service Arch 2022-12-12, Sharding NYC 2023-07-24
Participants:
Story Points: 5

 Description   

The current Shard::runCommand function is blocking, which means that clients who need to contact a shard in an asynchronous fashion are required to implement retry logic on their own. It would be good to have an asynchronous version of runCommand that appropriately handles retry logic. The implementation may be a free function rather than part of the Shard interface if it is more convenient.

 

Update: we're going to rewrite Shard::runCommand to use the async_rpc API to do this. 



 Comments   
Comment by Matthew Saltz (Inactive) [ 20/May/21 ]

As part of this ticket, I was attempting to integrate this new function into the AsyncRequestsSender as a way to make sure the new functionality was correct. However, it turned out to be difficult to make changes to the ARS without breaking things in subtle and hard to find ways, so I made two prerequisite tickets to this one.

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