-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Networking & Observability
-
ALL
-
None
-
None
-
None
-
None
-
None
-
None
-
None
There is specifically a cycle of STEP::_mutex --> ShardREgistry::_mutex --> RSMM::_mutex --> STEP::_mutex).
An example manifestation would be:
STEP mutex is taken while holding RSMM mutex via RSMM::removeMonitor --> StreamableRSM::drop --> STEP::REplicaSetChangeListener::onDroppedSet
RSM mutex taken while holding ShardREgistry mutex via ShardingReplicaSetChangedLitener::onConfirmedSet --> ShardRegistry::updateReplSetHosts --> ShardFactory::createShard --> RSMM::getOrCreateMonitor
SR mutex taken while holding STEP mutex via ConnectionPool::get --> STEP::addHost --> ShardRegistry::isConfigServer --> ShardRegistry::getConfigShard
- is caused by
-
SERVER-67912 Reduce set of non-causally consistent API of the ShardRegistry
-
- Closed
-
- is related to
-
SERVER-91826 Lock order inversion between EgressConnectionCloserManager::_mutex, ShardRegistry::_mutex, and ConnectionPool::_mutex
-
- Backlog
-
-
SERVER-91827 Lock order inversion between ConnectionPool::_mutex, ShardRegistry::_mutex, ReplicationCoordinatorImpl::_mutex, ReplicationCoordinatorExternalStateImpl::_threadMutex, and EgressConnectionCloserManager::_mutex
-
- Backlog
-
-
SERVER-62656 Decouple mongos-to-config-server connection pool sizing from mongos-to-shard-server connection pool sizing
-
- Closed
-
- related to
-
SERVER-88159 mongo::Mutex masks TSAN's ability to detect a lock order inversion
-
- Closed
-