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

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

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Gone away
    • Icon: Major - P3 Major - P3
    • None
    • None
    • Sharding
    • None
    • ALL
    • Sharding 2020-09-21, Sharding 2020-10-05, Sharding 2020-10-19
    • 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

        Activity

          People

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

            Dates

              Created:
              Updated:
              Resolved: