Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-81910

Consider making "maxAwaitTimeMS" for streamable hello command configurable

    • Type: Icon: Task Task
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Cluster Scalability

      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". 

            Assignee:
            backlog-server-cluster-scalability [DO NOT USE] Backlog - Cluster Scalability
            Reporter:
            cheahuychou.mao@mongodb.com Cheahuychou Mao
            Votes:
            0 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated: