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

    • Type: Task
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.1.9
    • Component/s: Sharding
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Sprint:
      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

            Assignee:
            esha.maharishi Esha Maharishi
            Reporter:
            esha.maharishi Esha Maharishi
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: