-
Type:
New Feature
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Internal Code
-
Cluster Scalability
-
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
-
5
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.
- depends on
-
-
- Closed
-
-
SERVER-57087 Write unit tests for the AsyncRequestsSender
-
- Backlog
-
-
-
- Backlog
-
-
-
- Closed
-
- duplicates
-
-
- Closed
-
- has to be done before
-
SERVER-65892 `Shard::runCommandWithFixedRetryAttempts` must not ignore OperationContext's deadline
-
- Backlog
-
- is depended on by
-
-
- Backlog
-
-
-
- Closed
-
- is related to
-
-
- Closed
-
-
SERVER-78557 Allow targeting to wait until there is a significant topology change before using a retry
-
- Backlog
-
- related to
-
-
- Closed
-