[SERVER-31198] Run the concurrency suite with shard stepdowns Created: 21/Sep/17  Updated: 30/Oct/23  Resolved: 04/Jan/18

Status: Closed
Project: Core Server
Component/s: Sharding, Testing Infrastructure
Affects Version/s: None
Fix Version/s: 3.6.4, 3.7.1

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

Issue Links:
Backports
Depends
Duplicate
is duplicated by SERVER-20982 Add concurrency workload framework to... Closed
is duplicated by SERVER-21052 Add a failover workload to cause intr... Closed
Problem/Incident
Related
related to SERVER-43485 Validate TODO listed in SERVER-31198 Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v3.6
Sprint: Sharding 2017-10-02, Sharding 2017-10-23, Sharding 2017-11-13, Sharding 2017-12-04, Sharding 2018-01-01, Sharding 2018-01-15, Sharding 2017-12-18
Participants:
Linked BF Score: 0

 Description   

Update the jstests/concurrency/fsm_all_sharded_with_stepdowns.js and jstests/concurrency/fsm_all_sharded_with_stepdowns_and_balancer.js files to specify

{
  sharded: {enabled: true, stepdownOptions: {configStepdown: true, shardStepdown: true}},
  replication: {enabled: true}
}

as the cluster options. Since mongos won't automatically retry any operations destined for the shards, we'll want to additionally load() the jstests/libs/override_methods/auto_retry_on_network_error.js override from SERVER-30953 when shardStepdown=true inside of worker_thread.js similar to what's done for implicitly retrying on "DatabaseDropPending" error responses.



 Comments   
Comment by Githook User [ 07/Mar/18 ]

Author:

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

Message: SERVER-31198 Use modified version of commandObj in retries.

(cherry picked from commit 3a6dfd6810235e678367d3cff5f74fb1eeb971d9)
Branch: v3.6
https://github.com/mongodb/mongo/commit/9282936b2b0b997b1efd847a7e422811c47c70f9

Comment by Githook User [ 07/Mar/18 ]

Author:

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

Message: SERVER-31198 Run the concurrency suite with shard stepdowns

(cherry picked from commit 876f24aefbb0e0cf9fac30980b9ddea52d133fc9)
Branch: v3.6
https://github.com/mongodb/mongo/commit/401181d1bc9782fe864d26f9345edbaeb7a16746

Comment by Githook User [ 04/Jan/18 ]

Author:

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

Message: SERVER-31198 Use modified version of commandObj in retries.
Branch: master
https://github.com/mongodb/mongo/commit/3a6dfd6810235e678367d3cff5f74fb1eeb971d9

Comment by Max Hirschhorn [ 04/Jan/18 ]

Re-opening this ticket to address failures observed during the plan_cache_drop_database.js FSM workload. The changes to implicitly_retry_on_database_drop_pending.js in 876f24a made it so that the commandObj specified by the caller would no longer be mutated; however, the runCommandWithRetries() was depending on mutating the commandObj parameter in order to update the reference in funcArgs implicitly.

https://evergreen.mongodb.com/task/mongodb_mongo_master_enterprise_rhel_62_64_bit_concurrency_replication_WT_876f24aefbb0e0cf9fac30980b9ddea52d133fc9_18_01_03_20_10_57

Comment by Githook User [ 03/Jan/18 ]

Author:

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

Message: SERVER-31198 Run the concurrency suite with shard stepdowns
Branch: master
https://github.com/mongodb/mongo/commit/876f24aefbb0e0cf9fac30980b9ddea52d133fc9

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