Re: Re: Deadlock in Java9.getDefaultImportClasses() ?

Am Dienstag, dem 09.04.2024 um 14:34 +0000 schrieb Mutter, Florian:
> 
> 
> We found the issue: On the cluster with the new kubernetes version
> the application did start on a smaller node. The node has only 8
> cores. The common ForkJoinPool was only 1/4th of the size. It seems
> that the application uses a lot of long running threads (e.g. for
> consuming kafka messages) and never allowed the groovy tasks to run.
> Setting -XX:ActiveProcessorCount to 16 or something higher did fix
> the issue.
> 
> Maybe groovy should create it's own thread pool to not interfere with
> other parts of the application. On the other hand if this only runs
> on startup maybe an extra thread pool is overkill.

Indeed. Tricks with -XX:ActiveProcessorCount should not be necessary to
make Groovy startup successfully.

For all applications that use CompletableFuture.supplyAsync(), I
strongly suggest a custom thread pool in a custom CompletableFuture
implementation so the application can not suffer thread starvation at
startup so easily.

And yes, ramping up several custom thread pools is a high price to pay
for avoiding CompletableFuture.supplyAsync() sharing the common pool.

So maybe it is a good idea to just revoke this commit

https://github.com/apache/groovy/commit/501f7547fd80663eaa17c6504f9c6d1ee3f4bc28

To me it looks like overoptimization, hiding the risk of using
CompletableFuture's common pool.

Best regards,

Jörg