[SERVER-30682] Run the concurrency suite with "secondary" read preference Created: 16/Aug/17  Updated: 30/Oct/23  Resolved: 15/Sep/17

Status: Closed
Project: Core Server
Component/s: Sharding, Testing Infrastructure
Affects Version/s: None
Fix Version/s: 3.6.0-rc0

Type: Task Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Jack Mulrow
Resolution: Fixed Votes: 0
Labels: sharding36-passthrough-testing
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-30681 Run the concurrency suite with causal... Closed
Related
related to SERVER-31456 Concurrency framework doesn't enforce... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2017-09-11, Sharding 2017-10-02
Participants:

 Description   

We should extend the work from SERVER-30681 to use a readPreference of "secondary" in order to gain testing coverage of the "Secondaries chunk aware" project. When {sharding: {enabled: true}} is used as the cluster options, then the collections prepared by the concurrency framework are automatically sharded (typically using an {_id: "hashed"} shard key).

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();
        myDB.getMongo().setReadPref("secondary");
    }
}

Note: FSM workloads that use a unique collection or database name in order to avoid highly-destructive actions for other FSM workloads won't use a sharded collection. Additionally, FSM workloads that drop the collection or database as part of their state functions won't re-create the collection as a sharded collection. We should try experimenting with implicitly_shard_accessed_collections.js override to automatically create (or re-create) the collection as a sharded collection in these cases. It's possible that similar to the sharded_collections_jscore_passthrough.yml test suite, some FSM workloads may have internal assertions or invariants that get violated if a collection was known to have been dropped by an FSM worker thread comes back on its own.



 Comments   
Comment by Ramon Fernandez Marina [ 15/Sep/17 ]

Author:

{'username': u'jsmulrow', 'name': u'Jack Mulrow', 'email': u'jack.mulrow@mongodb.com'}

Message:SERVER-30682 Run the concurrency suite with "secondary" read preference

Previously committed with an incorrect SERVER ticket number.
Branch:master
https://github.com/mongodb/mongo/commit/1d4dd376cee7833959496af5aede4de6c23e39ed

Generated at Thu Feb 08 04:24:39 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.