[SERVER-21522] $config.data is reused across executions of the same workload in parallel and composed modes Created: 18/Nov/15  Updated: 25/Nov/15  Resolved: 19/Nov/15

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: 3.2.0-rc3
Fix Version/s: 3.2.0-rc4

Type: Bug Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Max Hirschhorn
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-21499 Enable fsm_all_simultaneous.js (FSM p... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

Apply the following patch to define a workload that checks the initialization of the $config.data and then create a schedule that runs it multiple times:

python buildscripts/resmoke.py --executor concurrency jstests/concurrency/fsm_all.js

diff --git a/jstests/concurrency/fsm_libs/runner.js b/jstests/concurrency/fsm_libs/runner.js
index 4d0cea5..2198097 100644
--- a/jstests/concurrency/fsm_libs/runner.js
+++ b/jstests/concurrency/fsm_libs/runner.js
@@ -600,6 +600,14 @@ var runner = (function() {
                 bgThreadMgr.checkFailed(0);
 
                 var schedule = scheduleWorkloads(workloads, executionMode, executionOptions);
+                schedule = [
+                    [
+                        "jstests/concurrency/fsm_workloads/noop.js",
+                    ],
+                    [
+                        "jstests/concurrency/fsm_workloads/noop.js",
+                    ],
+                ];
                 printWorkloadSchedule(schedule, bgWorkloads);
 
                 schedule.forEach(function(workloads) {
diff --git a/jstests/concurrency/fsm_workloads/noop.js b/jstests/concurrency/fsm_workloads/noop.js
new file mode 100644
index 0000000..131fad7
--- /dev/null
+++ b/jstests/concurrency/fsm_workloads/noop.js
@@ -0,0 +1,26 @@
+'use strict';
+
+var $config = (function() {
+
+    var states = { noop: function noop(db, collName) {} };
+    var transitions = { noop: { noop: 1 } };
+
+    function setup(db, collName, cluster) {
+        assertAlways.eq(0, this.counter,
+                        '"counter" property on $config.data was not initially zero');
+        this.counter++;
+    }
+
+    return {
+        threadCount: 1,
+        iterations: 10,
+        startState: 'noop',
+        states: states,
+        transitions: transitions,
+        data: {
+            counter: 0
+        },
+        setup: setup
+    };
+
+})();

Sprint: QuInt C (11/23/15)
Participants:

 Description   

The issue is that loadWorkloadContext() is called once during initialization to set up the context object and the same context object is used when running the entire schedule. Proposal is to create a separate object with its own copy of the $config objects during each phase of the schedule of the foreground workloads that are executed.

Note that this does not affect any of the active fsm_all_xx.js tests that run in Evergreen because the ls() function in the mongo shell does not return duplicate entries and the scheduleWorkloads() function does not execute a workload multiple times when doing serial execution.

[js_test:fsm_all] 2015-11-17T23:54:24.153-0500 2015-11-17T23:54:24.151-0500 E QUERY    [thread1] Error: [0] != [1] are not equal : "counter" property on $config.data was not initially zero :
[MongoDFixture:job0] 2015-11-17T23:54:24.153-0500 I NETWORK  [conn2] end connection 127.0.0.1:55241 (0 connections now open)
[js_test:fsm_all] 2015-11-17T23:54:24.154-0500 quietlyDoAssert@jstests/concurrency/fsm_libs/assert.js:53:15
[js_test:fsm_all] 2015-11-17T23:54:24.154-0500 assert.eq@src/mongo/shell/assert.js:49:5
[js_test:fsm_all] 2015-11-17T23:54:24.154-0500 wrapAssertFn@jstests/concurrency/fsm_libs/assert.js:60:13
[js_test:fsm_all] 2015-11-17T23:54:24.154-0500 assertWithLevel/</assertWithLevel[fn]@jstests/concurrency/fsm_libs/assert.js:99:13
[js_test:fsm_all] 2015-11-17T23:54:24.155-0500 setup@jstests/concurrency/fsm_workloads/noop.js:9:1
[js_test:fsm_all] 2015-11-17T23:54:24.155-0500 setupWorkload@jstests/concurrency/fsm_libs/runner.js:351:9
[js_test:fsm_all] 2015-11-17T23:54:24.155-0500 runWorkloadGroup/<@jstests/concurrency/fsm_libs/runner.js:468:17
[js_test:fsm_all] 2015-11-17T23:54:24.155-0500 runWorkloadGroup@jstests/concurrency/fsm_libs/runner.js:460:13
[js_test:fsm_all] 2015-11-17T23:54:24.155-0500 runWorkloads/<@jstests/concurrency/fsm_libs/runner.js:621:1
[js_test:fsm_all] 2015-11-17T23:54:24.156-0500 runWorkloads@jstests/concurrency/fsm_libs/runner.js:613:17
[js_test:fsm_all] 2015-11-17T23:54:24.156-0500 serial@jstests/concurrency/fsm_libs/runner.js:655:13
[js_test:fsm_all] 2015-11-17T23:54:24.156-0500 @jstests/concurrency/fsm_all.js:10:1
[js_test:fsm_all] 2015-11-17T23:54:24.156-0500
[js_test:fsm_all] 2015-11-17T23:54:24.156-0500 failed to load: jstests/concurrency/fsm_all.js



 Comments   
Comment by Githook User [ 19/Nov/15 ]

Author:

{u'username': u'visemet', u'name': u'Max Hirschhorn', u'email': u'max.hirschhorn@mongodb.com'}

Message: SERVER-21522 Make a copy of the $config before running a workload.

Mutating the "threadCount" property in the ThreadManager is now safe
because subsequent executions of a workload group in the schedule will
use fresh $config objects. The proportion of workloads within the group
will be based off the number of threads initially requested, even if a
previous workload needed to be scaled down.
Branch: master
https://github.com/mongodb/mongo/commit/721048cbc4e6b7d250cd729967b94e244426156d

Generated at Thu Feb 08 03:57:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.