[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: |
| 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: |