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

Make drop collection in concurrency workloads retry LockBusy errors

    • Type: Icon: Bug Bug
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Sharding
    • Labels:
    • Sharding
    • ALL
    • Sharding 2017-11-13
    • 29

      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.


      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.

            backlog-server-sharding [DO NOT USE] Backlog - Sharding Team
            dianna.hohensee@mongodb.com Dianna Hohensee (Inactive)
            0 Vote for this issue
            4 Start watching this issue