> com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from TEST > scope at
This is because the test suite extends RandomizedTest and this in turn enables a feature of the runner named aptly "thread leak detection". The problem is that if you spawn threads from a test and then return to the framework those threads running in the background may affect further computations and be very difficult to debug. The runner detects such cases and fails a test that didn't clean up after itself properly. There are a few workarounds: 1) do clean up; after the test is over all threads it possibly starts should be join()'ed with. 2) sometimes the above is not possible explicitly -- as with executors, for example. If it's known that threads may linger a bit but will eventually terminate a @ThreadLeakLingering(linger = 20000) can be applied which gives the maximum time to wait for stray threads. They still must terminate. 3) sometimes threads should last for the entire suite's duration. The scope of detection can be changed with @ThreadLeakScope(Scope.SUITE). 4) finally, if this all is not really needed the feature can be disabled by @ThreadLeakScope(Scope.NONE). I honestly think this is the worst scenario though because leaked threads are *very* difficult to debug if they do something wrong and affect test results. Take a look at class annotations of: http://goo.gl/n7rYD for an example of multiple configuration directives used in real life: @ThreadLeakScope(Scope.SUITE) @ThreadLeakGroup(Group.MAIN) @ThreadLeakAction({Action.WARN, Action.INTERRUPT}) @ThreadLeakLingering(linger = 20000) // Wait long for leaked threads to complete before failure. zk needs this. @ThreadLeakZombies(Consequence.IGNORE_REMAINING_TESTS) @TimeoutSuite(millis = 2 * TimeUnits.HOUR) @ThreadLeakFilters(defaultFilters = true, filters = { QuickPatchThreadsFilter.class }) Dawid
