[SERVER-19662] Assert that mongod never refreshes the sharding metadata under a lock Created: 30/Jul/15 Updated: 14/Apr/16 Resolved: 17/Mar/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.3.4 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Kaloian Manassiev | Assignee: | Kaloian Manassiev |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Sharding 8 08/28/15, Sharding F (01/29/16), Sharding 10 (02/19/16), Sharding 11 (03/11/16), Sharding 12 (04/01/16) | ||||||||
| Participants: | |||||||||
| Description |
|
This ticket is to add invariants in the places where we refresh sharding metadata, in order to ensure we never do that under a lock. Holding a lock during network operations is undesirable, because it may delay step down, which needs a global X lock. |
| Comments |
| Comment by Kaloian Manassiev [ 17/Mar/16 ] |
|
Fixed by https://github.com/mongodb/mongo/commit/ee5fbdd8540d93d2e0d6fa19ba9a5595bb1829cb |
| Comment by Kaloian Manassiev [ 14/Jan/16 ] |
|
This is not related to rolling CSRS upgrade. Just a nice to have validation that long-running network calls do not make a replica set primary unusable because they are holding the global lock. |
| Comment by Spencer Brody (Inactive) [ 14/Jan/16 ] |
|
kaloian.manassiev, is this actually related to rolling CSRS upgrade, or is this just something that would always have been a good idea that we were hoping to get done now? |