[SERVER-27789] Increase timeouts in commands_that_write_accept_wc_* Created: 23/Jan/17  Updated: 06/Dec/17  Resolved: 15/Jun/17

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 3.4.6, 3.5.9

Type: Bug Priority: Major - P3
Reporter: Judah Schvimer Assignee: Esha Maharishi (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Duplicate
is duplicated by SERVER-29426 Write timeout values in commands_that... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v3.4
Sprint: Sharding 2017-06-19
Participants:
Linked BF Score: 0

 Description   

commands_that_write_accept_wc_configRS.js and commands_that_write_accept_wc_shards.js still have fairly low wtimeouts of 25 seconds. These should be increased to 5 minutes so that timeouts truly indicate bugs.

We should also add calls to awaitReplication at the beginning of each call to "dropTestData" on each replicaset in the cluster to make sure that any non-replicated writes get replicated before calling dropUser (which requires writes to replicate on the config servers) or testing a new command.



 Comments   
Comment by Githook User [ 15/Jun/17 ]

Author:

{u'username': u'EshaMaharishi', u'name': u'Esha Maharishi', u'email': u'esha.maharishi@mongodb.com'}

Message: SERVER-27789 Increase timeouts in commands_that_write_accept_wc_*
Branch: v3.4
https://github.com/mongodb/mongo/commit/2da98515dc96a8e9ae329200fc251db66f893ac0

Comment by Githook User [ 15/Jun/17 ]

Author:

{u'username': u'EshaMaharishi', u'name': u'Esha Maharishi', u'email': u'esha.maharishi@mongodb.com'}

Message: SERVER-27789 Increase timeouts in commands_that_write_accept_wc_*
Branch: master
https://github.com/mongodb/mongo/commit/96d35cfa5c3212124e0ffdbdcb81a26565b022e3

Comment by Judah Schvimer [ 02/Jun/17 ]

The timeout here should also be raised a bit. This is complicated because the timeout needs to be high enough to succeed consistently on the config servers but also will time out every time on the shards so it can't be too high. Setting the timeout a bit higher to 10 or 20 seconds or so should make it significantly more reliable without slowing down the test quite so much. Alternatively we could remove this case, but that reduces our test coverage a bit.

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