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

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

    • Type: Icon: Bug Bug
    • Resolution: Gone away
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Sharding
    • None
    • ALL
    • Sharding 2020-09-21, Sharding 2020-10-05, Sharding 2020-10-19
    • 13

      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.

            Assignee:
            lamont.nelson@mongodb.com Lamont Nelson
            Reporter:
            matthew.saltz@mongodb.com Matthew Saltz (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: