[SERVER-20654] Create fail point to make distributed lock timeout 10 minutes for dropCollection Created: 25/Sep/15  Updated: 07/Oct/15  Resolved: 01/Oct/15

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

Type: Task Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Esha Maharishi (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Sharding A (10/09/15)
Participants:

 Description   

When testing sharding commands in the fsm concurrency suite, the high volume of traffic on the distributed lock often causes the dropCollection command to return a LockBusy error simply because other sharding commands such as moveChunk, mergeChunks, and splitChunk are still running and/or contending on the distributed lock.

Having the timeout set to a much higher value (but still lower than the lock takeover timeout) allows for:
1) test readability and simplicity: a failure in the test corresponds to an actual failure.
2) exercising the server's retry logic rather than the test's.



 Comments   
Comment by Githook User [ 29/Sep/15 ]

Author:

{u'username': u'EshaMaharishi', u'name': u'Esha Maharishi', u'email': u'esha.maharishi@10gen.com'}

Message: SERVER-20654 create fail point to make distributed lock timeout 10 minutes for dropCollection
Branch: master
https://github.com/mongodb/mongo/commit/a2da29e9188b27bdff7b63db21720390b4a98d01

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