TCK: BulkheadMetricTest is hanging when failing

Method newWaitingFuture() in BulkheadMetricTest generates CompletableFuture with direct instantiation (i.e. new CompletableFuture<>()) and returns it. Later in test, we are waiting for this CompletableFuture completion with future.get() (in BulkHeadMetricBean#doWaitFor()). On Java SE this goes in an endless waiting loop. Tested on Oracle JVM 1.8.0_172-b11 and 9.04

This can be easily reproduced by running the following code:

 public class FutureTest {
    public static void main(String[] args) {
        FutureTest ft = new FutureTest();
        ft.run();
    }

    CompletableFuture<Void> f;

    public FutureTest() {
        f = new CompletableFuture<>();
    }

    public void run()  {
        try {
            f.get();
        } catch (InterruptedException | ExecutionException e) {
            e.printStackTrace();
        }
        System.out.println("Done !");
    }
}

To fix this, we should generate these CompletableFuture with CompletableFuture.runAsync(() -> {}) instead of new

[antoinesd]

Changing @AfterTest to @AfterMethod correct the issue. I send a PR

[Azquelt]

bulkheadMetricTest. Right now test should fail because I don’t register required metrics. the failure should occur in MetricGetter#getGaugeValue when the first assertThat on line 100 is called. When debugging I can see exception treatment (NoSuchElementException) but it doesn’t stop the test which continue indefinitely.

I’m a bit surprised. Although I can understand that this might leave the async thread running, I’m surprised that that causes the whole test run to stop, even after the test method has thrown the exception. I guess something somewhere is must be waiting for all background threads to stop? Possibly when the app is undeployed?

I also spot a mistake. The method completeWaitingFutures is meant to run at the end of each test method and will complete any futures that are still waiting. I’ve annotated it with @AfterTest when it should be @AfterMethod (I’m more used to junit and thinking about each method as a “test”). It would be good to know whether changing that is sufficient to stop your test hanging (ideally we don’t even want to be waiting around for timeouts in the case of a failure).