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

Investigate concurrency suite timeouts with causal consistency and secondary read preference

    • Fully Compatible
    • ALL
    • Sharding 2017-10-02, Sharding 2017-10-23, Sharding 2017-11-13, Sharding 2017-12-04
    • 0

      In the causal consistency secondary read preference suite, there are a few workloads that sometimes timeout. Currently they are blacklisted, but their causes should be investigated so the tests can be re-enabled.

      The known workloads are:

      • update_multifield_multiupdate_noindex.js
      • indexed_insert_multikey.js
      • indexed_insert_multikey_noindex.js

      *note
      For some of the failures, the fsm log output claims that the hung workload "completed" in roughly 6 hours, but this is misleading because if the test registers as timed out, attaching GDB to the hung process can cause the others to break out of their hang long enough for the workload to continue for a short period of time (possibly by changing their perception of that node to "down" instead of whatever was causing the hang). So even though some logs may claim the hung workload eventually completed, it's very likely it did not.

            Assignee:
            misha.tyulenev@mongodb.com Misha Tyulenev (Inactive)
            Reporter:
            jack.mulrow@mongodb.com Jack Mulrow
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: