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
