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

Make drop collection in concurrency workloads retry LockBusy errors

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Duplicate
    • None
    • None
    • Sharding
    • None
    • ALL
    • Sharding 2017-11-13
    • 29

    Description

      Sharding metadata commands often take collection distributed locks. Drop collection on a sharded collection takes distlocks. Concurrency suites cannot / do not handle the LockBusy errors that can arise due to concurrent metadata commands, drop collection being more popular than the other metadata commands in our current concurrency tests.

      view_catalog_cycle_with_drop.js is a frequently failing workload. kill_aggregation.js (kill_rooted_or.js) failed, too, and drop_collection.js workload.

      Concurrency workloads should not be running drop collection commands. Drop collection during set up between concurrency tests is fine – no concurrency --, but not in the workloads themselves.

      UPDATE:

      Rather than removing drop collection from concurrency workloads, make LockBusy on drop collection/database commands retryable in the concurrency suites. See the comments for similar cases we've handled in the JS.

      Attachments

        Issue Links

          Activity

            People

              backlog-server-sharding Backlog - Sharding Team
              dianna.hohensee@mongodb.com Dianna Hohensee
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: