In 3.2 we run many commands through the ShardRegistry, instead of using DBClient directly. We wanted to always use a 30 second timeout for all commands sent to the config servers through the ShardRegistry, but in doing so we accidentally started using the 30 second timeout for commands run against shards as well, where it may not be right to do so.
- is duplicated by
-
SERVER-23820 "Operation timed out" when enableSharding on large collection in Microsoft Azure
- Closed
-
SERVER-27515 Issue with sharding a huge collection(splitVector timeout)
- Closed
- is related to
-
SERVER-23487 Issue with Sharding Collection SplitVector timeout
- Closed
- related to
-
SERVER-23782 make Shard::_runCommand and Shard::_exhaustiveFindOnConfig take a timeout argument
- Closed