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

Concurrent sharded fuzzers should not run mapReduces with replace

    XMLWordPrintable

Details

    • Task
    • Status: Closed
    • Major - P3
    • Resolution: Won't Fix
    • 3.6.8, 4.0.3, 4.1.4
    • None
    • MapReduce, Sharding
    • None
    • Sharding 2019-02-25, Sharding 2019-03-11, Sharding 2019-03-25
    • 53

    Description

      Concurrent mapReduces with replace are not supported. As part of the cluster's map reduce logic, we will always drop the output collection then shard it again. Since these two operations are not atomic, it can leads to a race condition where two mapReduces can simultaneously output to the same collection with the same UUID.

      With mapReduce A and B, in order:

      1. mapReduce A drops the output collection
      2. mapReduce B drops the output collection
      3. mapReduce A creates the sharded output collection with a generated UUID
      4. mapReduce B attempts to shard the output collection, but when doing is told that the collection is already sharded and receives the UUID that mapReduce A generated.

      In order to avoid this undefined behavior, no sharded fuzzer suites (specifically: jstestfuzz_sharded_causal_consistency) should run mapReduce with replace.

      Attachments

        Issue Links

          Activity

            People

              blake.oler@mongodb.com Blake Oler
              blake.oler@mongodb.com Blake Oler
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: