[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:
Duplicate
duplicates SERVER-22359 Move MigrationSource Manager under co... Closed
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?

Generated at Thu Feb 08 03:51:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.