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

XMLWordPrintableJSON

    • Fully Compatible
    • v3.4
    • TIG 2017-03-06
    • 0
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      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.

              Assignee:
              Yves Duhem (Inactive)
              Reporter:
              Max Hirschhorn
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: