Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-13650

Investigate changes in SERVER-47972: maxTimeMS set on hedged requests does not give shards enough time to refresh

      Description

      Downstream Change Summary

      We've increased the default for maxTimeMSForHedgedReads here.

      Description of Linked Ticket

      Goal: investigate if the scenario outlined below is possible and determine a fix. 

       

      Scenario:

      Suppose shard0 has a primary, secondary0, and secondary1.

      • Each time mongos tries to perform 'count' with hedged reads, secondary0 never gets the chance to set the in memory database version because it either gets killedOp'd or timed out of maxTimeMS before it can be set successfully after refreshing.
      • Over the NetworkInterfaceTL, mongos tries to route the next 'count' command to secondary0. Secondary0 has no known databaseVersion, so onDbVersionMismatchNoExcept gets called. A refresh is prompted and errors with maxTimeMS expiration error.
      • Since the maxTimeMS error is ignored, the original "no known dbVersion" error propagates back to the NetworkInterfaceTL. There, since the error reported is not maxTimeMS, the finish line is triggered. Secondary0 wins the race, but the 'count' fails with "don't know dbVersion."

      In this scenario, we believe secondary0 would be getting killed here.

      Scope of changes

      Impact to Other Docs

      MVP (Work and Date)

      Resources (Scope or Design Docs, Invision, etc.)

            Assignee:
            kay.kim@mongodb.com Kay Kim (Inactive)
            Reporter:
            backlog-server-pm Backlog - Core Eng Program Management Team
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved:
              3 years, 49 weeks, 3 days ago