[ML] Fix unit test deadlock problem (#34174)

This change fixes a potential deadlock problem in the unit
test introduced in #34117.

It also removes a piece of debug code and corrects a docs
formatting problem that were both added in that same PR.
This commit is contained in:
David Roberts 2018-10-01 15:35:37 +01:00 committed by GitHub
parent 2e2ae19b97
commit a1d2ded98d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 3 additions and 3 deletions

View File

@ -1284,7 +1284,7 @@ If the request does not encounter errors, you receive the following result:
If you try to analyze a lot of data then the analysis will take a long time.
If you want to limit the amount of processing your {es} cluster performs for
a request, use the timeout query parameter. The analysis will be aborted and
a request, use the `timeout` query parameter. The analysis will be aborted and
an error returned when the timeout expires. For example, you can replace 20000
lines in the previous example with 200000 and set a 1 second timeout on the
analysis:

View File

@ -157,16 +157,16 @@ public class FileStructureFinderManagerTests extends FileStructureTestCase {
// Expected if timeout occurs and the input stream is closed before junk generation is complete
}
});
junkProducer.start();
try (InputStream bigInput = new PipedInputStream(generator)) {
junkProducer.start();
ElasticsearchTimeoutException e = expectThrows(ElasticsearchTimeoutException.class,
() -> structureFinderManager.findFileStructure(explanation, linesOfJunk - 1, bigInput, EMPTY_OVERRIDES, timeout));
assertThat(e.getMessage(), startsWith("Aborting structure analysis during ["));
assertThat(e.getMessage(), endsWith("] as it has taken longer than the timeout of [" + timeout + "]"));
explanation.add(e.getMessage());
}
// This shouldn't take anything like 10 seconds, but VMs can stall so it's best to