-
Type: Bug
-
Resolution: Gone away
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Internal Code
-
Labels:None
-
Service Arch
-
ALL
The change_streams_shards_start_in_sync.js test relies on the order in which the ARS runs commands against shards in order to succeed.
In particular, it:
- Uses mongobridge to disconnect one shard (Process A)
- Starts a changestream via a mongos (Process B)
- Waits for the changestream to start on the other shards (Process A)
- connects the shard (Process A)
- Now that the shard is connected, (Process B) finishes
Unfortunately, this relies on ordering in the AsyncRequestsSender. Because the ARS construction looks like:
For each request, use the ReplicaSetMonitor to target the request to a particular host, then call scheduleRemoteCommand. targeting via the rsm is a blocking operation.
Because of the mongobridge disconnect, this means that if you happen to target the disconnected shard before starting the other changestream, the test will hang for 20 seconds in targeting before failing.
One option would be to rewrite the replica set monitor to be fully async, at which point the order of targeting wouldn't matter.
- is related to
-
SERVER-39163 Perform parallel targeting in the ARS
- Closed