[SERVER-49430] Running hang analyzer in awaitSecondaryNodesForRollbackTest prevents further connections to nodes Created: 10/Jul/20  Updated: 29/Oct/23  Resolved: 14/Aug/20

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.7.0

Type: Bug Priority: Major - P3
Reporter: William Schultz (Inactive) Assignee: Vesselina Ratcheva (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-50048 minValid on another branch of history... Closed
Related
related to SERVER-43867 Work around unrecoverability of rollb... Closed
related to SERVER-49167 Update _setStableTimestampForStorage ... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2020-08-10, Repl 2020-08-24
Participants:

 Description   

In the ReplSetTest.awaitSecondaryNodesForRollbackTest function, we first call awaitSecondaryNodes, and if that times out, we then enter this section of logic to check for an unrecoverable rollback scenario. If the first awaitSecondaryNodes call times out, though, we trigger the hang analyzer which will suspend the mongod processes that we attach to. This prevents us from connecting to the nodes to run commands to check for unrecoverability. We should disable the hang analyzer for this awaitSecondaryNodes call (we can consider using MongoRunner.runHangAnalyzer.disable()), so that we can still connect to and run commands against nodes even after it times out.



 Comments   
Comment by Githook User [ 14/Aug/20 ]

Author:

{'name': 'Vesselina Ratcheva', 'email': 'vesselina.ratcheva@10gen.com', 'username': 'vessy-mongodb'}

Message: SERVER-49430 Do not run hang analyzer in awaitSecondaryNodesForRollbackTest
Branch: master
https://github.com/mongodb/mongo/commit/7656836e75b490d649d333cf0800c426819efa25

Comment by William Schultz (Inactive) [ 10/Jul/20 ]

This issue appeared a few times in my patch build here.

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