[SERVER-72896] Linearizable readConcern timeout for getMore is not configurable to values other than 15 seconds Created: 17/Jan/23  Updated: 29/Oct/23  Resolved: 16/Feb/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.0.0-rc0

Type: Improvement Priority: Major - P3
Reporter: Louis Williams Assignee: Jiawei Yang
Resolution: Fixed Votes: 0
Labels: repl-shortlist
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-70695 Use config fuzzer on sharded tests Closed
Related
related to SERVER-37948 Linearizable read concern is not sati... Closed
Assigned Teams:
Replication
Backwards Compatibility: Fully Compatible
Sprint: Repl 2023-02-20
Participants:
Linked BF Score: 0

 Description   

The linearizable readConcern timeout for getMore commands is hardcoded to 15 seconds. This value is used as the wtimeout for a no-op write.

In slow tests, 15 seconds may not be sufficient to avoid timeouts, and it is not adjustable, either.

Outside of getMore, we set the wtimeout to zero wait forever, so I'm not sure why getMore has different behavior.



 Comments   
Comment by Githook User [ 16/Feb/23 ]

Author:

{'name': 'Jiawei Yang', 'email': 'jiawei.yang@mongodb.com', 'username': 'YoungYang0820'}

Message: SERVER-72896 retry on linearizable read in jstest
Branch: master
https://github.com/mongodb/mongo/commit/533f1b8194120768a20039775eb070c2483e8a25

Comment by Louis Williams [ 14/Feb/23 ]

jiawei.yang@mongodb.com we don't need to set it to zero necessarily. We could raise the default to something higher than 15 seconds or make it configurable by the fuzzer. But if fixing the tests makes the most sense, that works too.

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