[SERVER-81910] Consider making "maxAwaitTimeMS" for streamable hello command configurable Created: 05/Oct/23  Updated: 31/Jan/24

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Cheahuychou Mao Assignee: Backlog - Cluster Scalability
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-81580 Make kDefaultConfigCommandTimeout con... Closed
Assigned Teams:
Cluster Scalability
Participants:

 Description   

The "maxAwaitTimeMS" option for a hello command determines the frequency of streamable hello responses from target mongos or mongod. Currently, the "maxAwaitTimeMS" used by the ReplicaSetMonitor is hardcoded to 10 seconds. That is, the ReplicaSetMonitor gets a hello response from a mongod every 10 seconds and every time there is a topology change. The ReplicaSetMonitor uses the hello responses to monitor not only the "serverType" (i.e. primary or secondary) of each mongod but also its "opTime" (i.e. lastDurableOpTime). For configsvr replica set, the "opTime" is used for "minClusterTime" (i.e. the "configOpTime" in the VectorClock) filtering which currently takes precedence over the "roundTripTime" window filtering. It turns out that the 10 seconds can make "opTime"s to be significantly more stale than "configOpTime", causing most of mongods to be filtered out during server selection, including ones that have low "roundTripTime" which should have been given priority in server selection when the readPreference is "nearest". 


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