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

Database cache does not use the 'allowLocks' option correctly

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 7.1.0-rc0, 6.0.10, 7.0.2, 5.0.22
    • Affects Version/s: 7.1.0-rc0, 5.0.19, 6.0.8, 7.0.0-rc8
    • Component/s: None
    • Labels:
    • Sharding EMEA
    • Fully Compatible
    • ALL
    • v7.0, v6.0, v5.0
    • Sharding EMEA 2023-07-10, Sharding EMEA 2023-07-24, Sharding EMEA 2023-08-07

      The ShardingWriteRouter uses an option called 'allowLocks' during catalog cache refreshes which, when true, causes the refresh to exit rather than blocking if the refresh cannot be fulfilled with local information. However, though the allowLocks setting is sent to the getDatabase call and checked as part of the tassert, there is no early exit in place for the database section.

      This means that the onInserts observer that uses the ShardingWriteRouter can end up blocking behind a catalog cache refresh.

      This problem is also blocking the fix for SERVER-78115. This ticket is adding a majority write back into the SSCCL, and in the case that the ShardingWriteRouter triggers an DB refresh, the majority write ends up blocked because the onInserts is keeping an oplog hole open.

            allison.easton@mongodb.com Allison Easton
            allison.easton@mongodb.com Allison Easton
            0 Vote for this issue
            5 Start watching this issue