From ce77a3dd6df984b27531e7d39f2b04dd56d0c316 Mon Sep 17 00:00:00 2001 From: David Roberts Date: Tue, 30 Jan 2018 16:34:16 +0000 Subject: [PATCH] [TEST] Make test more tolerant to slow VMs (elastic/x-pack-elasticsearch#3783) The test this change applies to has failed a couple of times on Windows VMs. Original commit: elastic/x-pack-elasticsearch@94e94d3ffdbec82b857708aadc70017294751d3d --- .../process/autodetect/AutodetectProcessManagerTests.java | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/plugin/ml/src/test/java/org/elasticsearch/xpack/ml/job/process/autodetect/AutodetectProcessManagerTests.java b/plugin/ml/src/test/java/org/elasticsearch/xpack/ml/job/process/autodetect/AutodetectProcessManagerTests.java index fe252d8e750..c182d756aa0 100644 --- a/plugin/ml/src/test/java/org/elasticsearch/xpack/ml/job/process/autodetect/AutodetectProcessManagerTests.java +++ b/plugin/ml/src/test/java/org/elasticsearch/xpack/ml/job/process/autodetect/AutodetectProcessManagerTests.java @@ -352,7 +352,12 @@ public class AutodetectProcessManagerTests extends ESTestCase { // Also close the job in the current thread, so that we have two simultaneous close requests manager.closeJob(jobTask, false, "in main test thread"); - closeThread.join(500); + // The 10 second timeout here is usually far in excess of what is required. In the vast + // majority of cases the other thread will exit within a few milliseconds. However, it + // has been observed that on some VMs the test can fail because the VM stalls at the + // wrong moment. A 10 second timeout is on a par with the length of time assertBusy() + // would wait under these circumstances. + closeThread.join(10000); assertFalse(closeThread.isAlive()); // Only one of the threads should have called AutodetectCommunicator.close()