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

Race condition when multiple fsyncLock() invocations made on a mongod instance.

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical - P2
    • Resolution: Fixed
    • Affects Version/s: 2.1.2
    • Fix Version/s: 3.4.0-rc3
    • Component/s: Concurrency
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Sprint:
      Integration 2016-10-31, Query 2016-11-21
    • Case:

      Description

      There is currently no specification for multiple agents attempting to fsyncLock() a mongod instance. However, the observed behavior is somewhat confusing. Observed behavior, from a single mongo shell:

      > db.runCommand({fsync: 1, lock: true})
      {
      	"info" : "now locked against writes, use db.fsyncUnlock() to unlock",
      	"seeAlso" : "http://dochub.mongodb.org/core/fsynccommand",
      	"ok" : 1
      }
      > db.runCommand({fsync: 1, lock: true})
      {
      	"info" : "now locked against writes, use db.fsyncUnlock() to unlock",
      	"seeAlso" : "http://dochub.mongodb.org/core/fsynccommand",
      	"ok" : 1
      }
      > db.fsyncUnlock()
      { "ok" : 1, "info" : "unlock completed" }
      > db.fsyncUnlock()
      { "ok" : 1, "info" : "unlock completed" }
      > db.fsyncUnlock()
      

      At first blush, this appears like the fsyncLock is a shared, recursive resource, and every acquisition must be paired with a release. However, this is misleading. What in fact happens is that the second acquisition returns, reporting success, if the first acquirer has the lock, and in the background on mongod, the lock request gets queued up. When the first acquisition is released with fsyncUnlock(), the pending lock request gets processed, and the fsync lock is re-acquired. There is a brief period where the fsync lock is unheld.

      We should:

      1. Fix the race condition, maintaining a locked read-only file set until all clients have unlocked.
      2. Make lock state clearer to clients, so that the message provides the information needed to understand current state.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              james.wahlin James Wahlin
              Reporter:
              tyler@10gen.com Tyler Brock
              Participants:
              Votes:
              4 Vote for this issue
              Watchers:
              18 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: