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

Increase the task timeout when running to the concurrency suite to 6 hours

    XMLWordPrintable

    Details

    • Backwards Compatibility:
      Fully Compatible
    • Backport Requested:
      v3.4
    • Sprint:
      TIG 2017-03-06
    • Linked BF Score:
      0

      Description

      There have been numerous cases where the concurrency* tasks time out on our OS X, ARM, and DEBUG builders because the machines are making slow progress. Since the fsm_all*.js tests actually runs other tests—namely the FSM workloads defined in the jstests/concurrency/fsm_workloads/ directory—it doesn't make sense to expect we'd be able finish running all of those tests within 2 hours. We should set the timeout_secs for the "run tests" function in the concurrency* tasks to 6 hours to work around how resmoke.py won't produce output until all of the FSM workloads have finished. This effectively corresponds to running the concurrency* task with only a exec_timeout_secs (default=6 hours) set. A separate project will be scheduled in the future to better integrate resmoke.py and the concurrency suite together so each FSM workload is recorded as a separate test case.

      We should also consider increasing the exec_timeout_secs of the concurrency_sharded* tasks to 12 hours because they run both fsm_all_sharded_replication.js and fsm_all_sharded_replication_with_balancer.js. This would help to avoid issues from running the concurrency_sharded_WT with --repeat=10 on the "Linux Repeated Execution" builder.

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: