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

find by UUID can return NamespaceNotFound for a collection that is concurrently renamed

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 4.0.0-rc5, 4.1.1
    • Storage
    • None
    • Fully Compatible
    • ALL
    • v4.0
    • Storage NYC 2018-05-21, Storage NYC 2018-06-04, Storage NYC 2018-06-18
    • 63

    Description

      The find command (and presumably any other command that needs to resolve UUIDs to namespaces), can return a NamespaceNotFound error on a collection that is concurrently renamed within the same database. If we try to execute a find command by UUID for a collection that exists but is being concurrently renamed, there is a race condition due to the fact that the find command resolves UUIDs to namespaces outside of its locks. For example, consider the following execution for a find and renameCollection command running on separate threads:

      Although accesses to the UUIDCatalog are made atomic by the catalog lock, different commands may still interleave their operations on the catalog in an arbitrary order, if not protected by stronger (database or collection level) locks.

      Attached is a repro (find_by_uuid_and_rename.js) demonstrating this issue. The race condition appears to be very narrow. Its probability is increased by adding a short sleep immediately after this line. Adding a mongo::sleepmillis(50) seemed sufficient.

      Attachments

        Issue Links

          Activity

            People

              maria.vankeulen@mongodb.com Maria van Keulen
              william.schultz@mongodb.com William Schultz (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: