Re: Groovy 4 compiler seems to leave behind Threads

> On 3 Feb 2022, at 16:16, Alexander Veit <[email protected]> wrote:
> 
> Hi,
> 
> after upgrading from Groovy 3.0.9 to 4.0.0 our test framework complains about remnant threads created by the Groovy compiler.
> 
> They are named "ForkJoinPool.commonPool-worker-N" where N is an integer number.
> 
> 1.) Can this behaviour be controlled? In the CompilerConfiguration and GroovyClassLoader I couldn't find a hint.
> 
> 2.) Is it possible to provide a custom ThreadFactoy?

They should get reclaimed over time, see javadoc for java.util.concurrent.ForkJoinPool. Excerpt:

All worker threads are initialized with Thread.isDaemon() set true.
A static commonPool() is available and appropriate for most applications. The common pool is used by any ForkJoinTask that is not explicitly submitted to a specified pool. Using the common pool normally reduces resource usage (its threads are slowly reclaimed during periods of non-use, and reinstated upon subsequent use).

In other words, don’t worry, it’s not a resource leak. :-) But if you really want to mess with it the javadoc should help, you can set the thread factory via a system property, for instance, as well as monitoring what it’s doing.

-- 
Rachel Greenham
[email protected]