Lingering threads in multiple tests

[aoli-al]

Guava Version

514f212

Description

While running Guava tests, I noticed multiple threads created by different tests that were left open.

Here is the incomplete list:

The thread pool was opened here, but the shutdown was not called.

guava/guava-tests/test/com/google/common/cache/CacheBuilderTest.java

Line 496 in 514f212

ExecutorService threadPool = Executors.newFixedThreadPool(nThreads);

In FuturesTest.java, multiple tests call newSingleThreadExecutor() without shutdown.

guava/guava-tests/test/com/google/common/util/concurrent/FuturesTest.java

Line 444 in 514f212

ListenableFuture<String> futureResult =

In TestThread.java, calling stop() may throw UnsupportedOperationException for the new version of Java. Thus, the join method will not be called. (maybe call interrupt when stop is not available?)

guava/guava-tests/test/com/google/common/util/concurrent/TestThread.java

Line 76 in 514f212

stop();

Example

Any test mentioned above.

Expected Behavior

The test should clean up threads.

Actual Behavior

Threads left open.

Packages

No response

Platforms

No response

Checklist

• I agree to follow the code of conduct.

• I can reproduce the bug with the latest version of Guava available.

[aoli-al]

#7320 addresses the lingering threads in CacheBuilderTest and FutureTest; however, the threads in TestThread are still not properly closed.

I tried to call thread.interrupt in TestThread::tearDown, but it does not work for UninterruptibleMonitorTest. Shall I create another issue to track this or just leave this issue open?

[cpovirk]

We probably should use interrupt() so that we at least get rid of the threads from InterruptibleMonitorTest. I think the threads from UninterruptibleMonitorTest are unavoidably stuck under newer versions of Java. That is not great, but it should be mostly harmless, I hope. (If we see bigger problems in the future, we could consider trying to run those tests in a separate VM (which I assume they are not run in currently) or even exclude them entirely from our external CI, leaving them to run internally (assuming that we don't see similar problems there :)).)

We should probably make our tearDown() method catch the UnsupportedOperationException from stop() while we're there. It doesn't fail the test, but it's probably spamming output. (We could still output something to acknowledge what's going on, but we could at least make it shorter than a full stack trace. And we probably don't need to bother at all if we leave a comment.)