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

Increase test-specific timeouts for roles lock acquisition

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 5.3.0, 5.0.9
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Fully Compatible
    • v5.0
    • Security 2021-06-14, Security 2021-06-28, Security 2021-07-12, Security 2021-07-26, Security 2021-08-09, Security 2021-12-13, Security 2021-12-27, Security 2022-01-10, Security 2022-01-24
    • 40

      BF-20601 indicates that the `dropRoles` transaction occasionally fails when it is unable to acquire an IX lock on the system.roles collection. This appears to occur exclusively in concurrency workloads with lock-free reads disabled, which involve numerous clients attempting to perform UMCs simultaneously. When lock-free reads are disabled, an S lock is taken on the system.roles collection every time a user needs to be loaded into memory from disk and every time the `usersInfo` command is run. As a result, all writes on the system.roles collection are not permitted during these periods to preserve consistency. It is likely that the `dropRoles` failures occurred due to concurrently-running operations that kept locking the system.roles collection.

      There are a couple of ways we can reduce the likelihood of this contention in highly-concurrent test workloads. 

      1. The default lock timeout is 5ms, which is likely sufficient for production workloads but too low for overloaded servers. We can try increasing it to a different default (i.e., 25ms) when testing commands are enabled.
      2. While the 'S' lock on the system.roles collection is necessary, it seems like there is a slight opportunity to reduce the size of the critical section during which it is held. The impact of this may be trivial, but it is likely in our best interest to minimize the time that the locks are held as much as possible.

            adam.rayner@mongodb.com Adam Rayner
            varun.ravichandran@mongodb.com Varun Ravichandran
            0 Vote for this issue
            5 Start watching this issue