Investigate hang in unit tests when ShardRegistry reload on fixed executor

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Won't Fix
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Sharding EMEA
    • ALL
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      The AsyncTry for reloading the ShardRegistry is causing hangs in some unit tests. As a temporary solution, it was needed to commit a special case only for unit tests performing a synchronous reload.

      For example, by just keeping the async reload, MigrationDestinationManagerGetIndexesAndCollectionsNoVersionsOrReadConcern is hanging after logging this line:

      {"t":{"$date":"2021-12-17T19:44:55.138Z"},"s":"I",  "c":"NETWORK",  "id":5440600, "ctx":"ShardRegistry-0","msg":"Scheduling request","attr":{"when":{"$date":"1970-01-01T00:00:00.001Z"},"request":"RemoteCommand 2 -- target:[DummyConfig:1234] db:config expDate:1970-01-01T00:00:30.001+00:00 cmd:{ find: \"shards\", maxTimeMS: 30000, readConcern: { level: \"majority\", afterOpTime: { ts: Timestamp(0, 0), t: -1 } } }"}}
      

      Attaching backtrace of the hang. The thread is stuck waiting on this condition variable

        1. backtrace_hang.txt
          5 kB
          Pierlauro Sciarelli

            Assignee:
            [DO NOT USE] Backlog - Sharding EMEA
            Reporter:
            Pierlauro Sciarelli
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: