-
Type: Bug
-
Resolution: Won't Fix
-
Priority: Major - P3
-
None
-
Affects Version/s: 3.2.0
-
Component/s: Sharding
-
None
-
Sharding
-
ALL
-
0
The outline for ShardRegistry::reload goes like this (as of 4b37c81ddfd33f550f2f42e1a14a56e427620db4):
1. Query config.shards.
2. Grab mutex.
3. Clear everything and repopulate from the query result.
The issue comes in when 2 threads calls reload and these threads got different results from the query at #1 (basically, they are state at different points in time). The newer one finishes first, and then the older one will overwrite the newer one after it grabs the lock. This will cause the ShardRegistry to contain the old entry until the next reload.
This is only a problem with SCCC because the CSRS implementation has a guard against this (Note: opTime is always zero for SCCC):
https://github.com/mongodb/mongo/blob/r3.2.0/src/mongo/s/client/shard_registry.cpp#L190-l195
- related to
-
SERVER-22797 Calls to ShardRegistry::reload needs to be serialized
- Closed