[SERVER-38749] Concurrent stepdown suites on 3.6 branch still use 5-second election timeout Created: 21/Dec/18  Updated: 06/Dec/22  Resolved: 21/Dec/18

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Backlog - Server Tooling and Methods (STM) (Inactive)
Resolution: Won't Fix Votes: 0
Labels: tig-concurrency
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
is related to SERVER-30642 Raise election timeouts as a way to p... Closed
Assigned Teams:
Server Tooling & Methods
Operating System: ALL
Participants:
Linked BF Score: 15
Story Points: 1

 Description   

The changes from 3aa3155 as part of SERVER-30642 were ineffective at increasing the election timeout for the concurrency_sharded_with_stepdowns*.yml test suites because the JavaScript version of the stepdown thread reconfigures the replica set and sets a 5 second election timeout by default. We should additionally additional set electionTimeoutMS=1 day as part of the stepdown options specified to the ContinuousStepdown.configure() function.

Note: This is no longer an issue for the 4.0 or master branches because they've switched to using the Python version of the stepdown thread, which doesn't reconfigure the replica set.



 Comments   
Comment by Max Hirschhorn [ 21/Dec/18 ]

Nevermind, I didn't think this one through - the JavaScript version of the stepdown thread depends on the replica members to run for election themselves rather than using the replSetStepUp command. I think we'll need to continue to be at risk of failovers not initiated by the stepdown thread until we switch over to the Python version.

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