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

$config.data is reused across executions of the same workload in parallel and composed modes

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 3.2.0-rc3
    • Fix Version/s: 3.2.0-rc4
    • Component/s: Testing Infrastructure
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Steps To Reproduce:
      Hide

      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
      +    };
      +
      +})();
      

      Show
      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)

      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
      

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: