-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Sharding, Testing Infrastructure
-
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.
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).
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
- depends on
-
SERVER-30680 Add support for session options to the concurrency framework
- Closed
- is depended on by
-
SERVER-30682 Run the concurrency suite with "secondary" read preference
- Closed
- related to
-
SERVER-31456 Concurrency framework doesn't enforce causal relationship between main thread and worker threads
- Closed