Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-20654

Create fail point to make distributed lock timeout 10 minutes for dropCollection

    XMLWordPrintable

Details

    • Task
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 3.1.9
    • Sharding
    • None
    • Fully Compatible
    • Sharding A (10/09/15)

    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.

      Attachments

        Activity

          People

            esha.maharishi@mongodb.com Esha Maharishi
            esha.maharishi@mongodb.com Esha Maharishi
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: