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

ShardRegistry::reload() competes with updates to the ShardRegistry through the RSM

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: In Progress
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 5.0 Required
    • Component/s: Sharding
    • Labels:
      None
    • Operating System:
      ALL
    • Sprint:
      Sharding 2020-09-21, Sharding 2020-10-05
    • Linked BF Score:
      13

      Description

      After addShard, we call ShardRegistry::reload() on the router so that the following request on the same client will be able to target that shard without receiving a ShardNotFound error. However, with the streamable replica set monitor, calls to onPossibleSet can then overwrite the host data on the ShardRegistry concurrently, leading to a ShardNotFound error on a subsequent request. It doesn't seem like there was ever a guarantee of shard add/remove operations being causally consistent with CRUD ops in any meaningful way, but this breaks tests that used to rely on the shard being available after addShard.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              lamont.nelson Lamont Nelson
              Reporter:
              matthew.saltz Matthew Saltz
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Dates

                Created:
                Updated: