[SERVER-34615] find by UUID can return NamespaceNotFound for a collection that is concurrently renamed Created: 23/Apr/18  Updated: 29/Oct/23  Resolved: 07/Jun/18

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.0.0-rc5, 4.1.1

Type: Bug Priority: Major - P3
Reporter: William Schultz (Inactive) Assignee: Maria van Keulen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File find_by_uuid_and_rename.js    
Issue Links:
Backports
Depends
Related
related to SERVER-29839 Protect against UUID->NSS mapping cha... Closed
related to SERVER-37384 Find by UUID must not return Namespac... Closed
related to SERVER-33632 Make UUID catalog reload atomic Closed
is related to SERVER-34531 listDatabases command can miss a data... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.0
Sprint: Storage NYC 2018-05-21, Storage NYC 2018-06-04, Storage NYC 2018-06-18
Participants:
Linked BF Score: 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.



 Comments   
Comment by Githook User [ 07/Jun/18 ]

Author:

{'username': 'mvankeulen94', 'name': 'Maria van Keulen', 'email': 'maria@mongodb.com'}

Message: SERVER-34615 Make UUIDCatalog updates for renameCollection atomic

(cherry picked from commit 7c12245583958023e35bce05d6b2212dcd7f24e3)
Branch: v4.0
https://github.com/mongodb/mongo/commit/b0309464e11c95eb512517cb644920e5f36e8eac

Comment by Githook User [ 06/Jun/18 ]

Author:

{'username': 'mvankeulen94', 'name': 'Maria van Keulen', 'email': 'maria@mongodb.com'}

Message: SERVER-34615 Make UUIDCatalog updates for renameCollection atomic
Branch: master
https://github.com/mongodb/mongo/commit/7c12245583958023e35bce05d6b2212dcd7f24e3

Comment by William Schultz (Inactive) [ 23/Apr/18 ]

This issue is to some extent already described in the comment thread on SERVER-33632, but this is a concrete example of how the issue could cause a command to return incorrect results.

Generated at Thu Feb 08 04:37:16 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.