[SERVER-31386] Make drop collection take the distlock before attempting routing table refresh Created: 04/Oct/17  Updated: 27/Oct/23  Resolved: 13/Oct/17

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Esha Maharishi (Inactive)
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-30733 Make DistLocks hierarchical for mongo... Closed
Sprint: Sharding 2017-10-23
Participants:
Linked BF Score: 0

 Description   

queryoptimizer3.js does drop collection commands in parallel, which can conflict. See the linked BF for a full description.

In summary, drop collection first refreshes it's routing metadata, then takes the distlock and proceeds to delete data and metadata under the protection of the distlock. The problem occurs when one drop collection command is running, has acquired the distlock, cleared shard data and cleared config.chunks entries, but not the config.collections entry. Then another drop collection command arrives and tries to refresh before getting blocked by the distlock. The refresh fails 10 times (ConflictingOperationInProgress), the command fails, and the test fails.

Drop collection should take the distlock before calling getCollectionRoutingInfo, so that the command cannot conflict with itself, and prevent changes to the metadata it sees.



 Comments   
Comment by Esha Maharishi (Inactive) [ 13/Oct/17 ]

Acquiring the distlocks for dropCollection was moved to before reading from the CatalogCache in SERVER-30733.

Generated at Thu Feb 08 04:26:53 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.