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

Run the concurrency suite with causal consistency enabled

    • Fully Compatible
    • Sharding 2017-09-11

      Until SERVER-30679 is implemented, setting causallyConsistentReads=true in the mongo shell's SessionOptions object won't cause "afterClusterTime" to be injected into the readConcern of the command request. In order to test the concurrency suite with causal consistency enabled without waiting on those changes, we should call Mongo.prototype.setCausalConsistency() on the FSM worker thread's connection directly.

      worker_thread.js
      if (args.sessionOptions !== undefined) {
          // Start session
          myDB = ...
      
          if (args.sessionOptions.causallyConsistentReads) {
              // TODO SERVER-30679: We manually enable causal consistency on the connection object so that
              // "afterClusterTime" is injected into the readConcern of any command requests through this
              // connection.
              myDB.getMongo().setCausalConsistency();
          }
      }
      

      New resmoke.py YAML suites and Evergreen tasks should be defined to run the concurrency suite with causal consistency enabled both when the balancer is enabled and when the balancer is not enabled. The reason to define them as separate test suites and Evergreen tasks is because that's ultimately the model we'll have once we move away from the concurrency framework having a JavaScript file to run other JavaScript files. Additionally, we'll avoid increasing the duration of the existing concurrency_sharded and concurrency_sharded_WT tasks (see SERVER-27858).

      concurrency_sharded_causal_consistency.yml
      test_kind: js_test
      
      selector: 
        roots: 
        - jstests/concurrency/fsm_all_sharded_causal_consistency.js
      
      # Concurrency tests that run against a sharded cluster start one themselves.
      executor: 
        config: 
          shell_options: 
            nodb: ''
            readMode: commands
      

      The jstests/concurrency/fsm_all_sharded_causal_consistency.js and jstests/concurrency/fsm_all_sharded_causal_consistency_and_balancer.js files should be adapted from jstests/concurrency/fsm_all_sharded_replication.js and jstests/concurrency/fsm_all_sharded_replication_with_balancer.js, respectively. The main difference between these files will be to specify

      {sessionOptions: {causallyConsistentReads: true}}
      

      as the execution options.

      Note: These JavaScript files should be excluded from all other concurrency*.yml test suites.

      Names of new resmoke.py YAML suites
      • concurrency_sharded_causal_consistency.yml
      • concurrency_sharded_causal_consistency_and_balancer.yml
      Names of new Evergreen tasks
      • concurrency_sharded_causal_consistency
      • concurrency_sharded_causal_consistency_WT
      • concurrency_sharded_causal_consistency_and_balancer
      • concurrency_sharded_causal_consistency_and_balancer_WT

      The new Evergreen tasks should be run on the following build variants:

      • Enterprise RHEL 6.2
      • Enterprise RHEL 6.2 (inMemory)
      • Windows 2008R2 DEBUG
      • SSL OS X 10.10
      • ASAN Enterprise SSL Ubuntu 16.04 DEBUG
      • UBSAN Enterprise Ubuntu 16.04 DEBUG
      • Enterprise RHEL 6.2 DEBUG Code Coverage

            Assignee:
            jack.mulrow@mongodb.com Jack Mulrow
            Reporter:
            max.hirschhorn@mongodb.com Max Hirschhorn
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: