Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
This issue is caused by allowing serverGlobalParams.featureCompatibility.isSchemaVersion36 to be set to false after the featureCompatibilityVersion document has been updated as part of FeatureCompatibilityVersion::set(). Consider the following sequence of events with two threads when the server starts out in featureCompatibilityVersion=3.6. Thread in {setFCV: "3.4"} Thread in {setFCV: "3.6"} | | | | FCV::set() called | | | fCV document changed to "3.4" | | | fCV global set to "3.4" via OpObserver | | | isSchemaVersion36 global set to false | via OpObserver | | | | | | FCV::set() called | | | fCV document changed to "3.6" | | | fCV global set to "3.6" via OpObserver | | | isSchemaVersion36 global set to true | via OpObserver | | | | isSchemaVersion36 global set to false | via setFCV |
esha.maharishi@10gen.com commented on Mon, 9 Oct 2017 15:18:41 +0000: Confirmed that this issue was fixed by SERVER-31209 and continued not to repro after SERVER-30793. geert.bosch commented on Thu, 5 Oct 2017 18:30:04 +0000: Per Max recommendation assigning to you for closing as duplicate. No need for additional regression testing, as existing tests are sufficient. Just manually run Max' test case when SERVER-30793 is fixed. esha.maharishi@10gen.com commented on Thu, 5 Oct 2017 18:29:35 +0000: I think we can run the repro_server31017.js after the changes from SERVER-30793 go in and confirm that the issue has been resolved. max.hirschhorn, sounds good. I'll link SERVER-30793 as related so we don't forget. max.hirschhorn@10gen.com commented on Thu, 5 Oct 2017 18:14:10 +0000: Thanks esha.maharishi, I wasn't sure whether SERVER-30793 would only impact the config servers or whether it would be for all usages of the "setFeatureCompatibilityVersion" command. I think we can run the repro_server31017.js after the changes from SERVER-30793 go in and confirm that the issue has been resolved. It also refactors the setFCV command so that isSchemaVersion36 is not set directly by the command. I suspect it will as a result of that change. esha.maharishi@10gen.com commented on Thu, 5 Oct 2017 18:11:43 +0000: max.hirschhorn if you agree, feel free to close this as a duplicate. Thanks louis.williams for finding this. esha.maharishi@10gen.com commented on Thu, 5 Oct 2017 18:08:13 +0000: I believe this problem will go away once SERVER-30793 is in. For one, that patch makes setFCV take an exclusive lock, so only one instance of it can run at a time. It also refactors the setFCV command so that isSchemaVersion36 is not set directly by the command.
python buildscripts/resmoke.py --suites=no_server repro_server31017.js repro_server31017.js (function() { "use strict"; load("jstests/libs/parallelTester.js"); // for ScopedThread and CountDownLatch const rst = new ReplSetTest({nodes: 1}); rst.startSet(); rst.initiate(); function setFCV(host, version, barrier) { const conn = new Mongo(host); barrier.countDown(); barrier.await(); try { assert.commandWorked(conn.adminCommand({setFeatureCompatibilityVersion: version})); return {ok: 1}; } catch (e) { return {ok: 0, error: e.toString(), stack: e.stack}; } } const primary = rst.getPrimary(); const db = primary.getDB("test"); while (true) { // We create two threads: one to set the server's featureCompatibilityVersion to "3.4" and // another to set the server's featureCompatibilityVersion to "3.6". { const barrier = new CountDownLatch(2); const thread34 = new ScopedThread(setFCV, primary.host, "3.4", barrier); const thread36 = new ScopedThread(setFCV, primary.host, "3.6", barrier); thread34.start(); thread36.start(); thread34.join(); thread36.join(); assert.commandWorked(thread34.returnData()); assert.commandWorked(thread36.returnData()); } // If the thread that sets the server's featureCompatibilityVersion to "3.4" did its update // to the featureCompatibilityVersion document last, then we reset the server's // featureCompatibilityVersion to "3.6" and try again. { const res = assert.commandWorked( db.adminCommand({getParameter: 1, featureCompatibilityVersion: 1})); if (res.featureCompatibilityVersion === "3.4") { assert.commandWorked(db.adminCommand({setFeatureCompatibilityVersion: "3.6"})); continue; } } // Otherwise, we implicitly create a collection via an insert operation and verify that // collections are always created with UUIDs when the server's featureCompatibilityVersion // is "3.6". { db.mycoll.drop(); assert.writeOK(db.mycoll.insert({})); const collectionInfos = db.getCollectionInfos({name: "mycoll"}); assert.eq(1, collectionInfos.length, tojson(collectionInfos)); assert(collectionInfos[0].info.hasOwnProperty("uuid"), "Expected collection to have a UUID since featureCompatibilityVersion is 3.6: " + tojson(collectionInfos)); } } rst.stopSet(); })();