-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extend ParallelExecutionConfiguration to specify a predicate for determing if a pool is saturated #2787
Comments
How would one supply the |
By implementing the new method in a custom implementation of @Override
public Predicate<? super ForkJoinPool> getSaturatePredicate() {
return (ForkJoinPool p) -> true;
} |
Thanks for the clarification. Wouldn't |
Yes, that does make more sense, even if the parameter name in the java.util.concurrent.ForkJoinPool constructor is named "saturate". |
Team decision: Add @klease Would you be interested in submitting a PR for this? |
Yes, of course. It will be my first for junit5 so I'll try to follow the guidelines. |
Add the method getSaturatePredicate to the interface ParallelExecutionConfiguration. This allows a custom configuration to supply a predicate to handle the case where the ForkJoinPool has reached the maximum pool size but all threads are currently blocked. Add a constructor to DefaultParallelExecutionConfiguration allowing to speciy the predicate and modify the existing constructor to specify null for the predicate. Modify DefaultParallelExecutionConfigurationStrategyTests to check the saturate predicate value in the default and custom configurations. Issue: junit-team#2787
This allows a custom configuration to supply a predicate to handle the case where the ForkJoinPool has reached the maximum pool size but all threads are currently blocked. Resolves #2787. Co-authored-by: Marc Philipp <mail@marcphilipp.de>
I'm working on the Apache Camel project which uses parallel execution on a module with a large number of test cases (over 2400 classes and over 6000 tests.) After upgrading to 5.7.2 or later we were getting RejectedExecutionException which we solved by using a custom configuration with a large value for maxPoolSize.
The cause appears to be that the Tasks for the test classes all call
ForkJoinPool.managedBlock
and the tests themselves can take up to a few seconds to run. Fairly quickly all threads in the ForkJoinPool are busy and therefore each new call to managedBock causes a new thread to be allocated up to the maxPoolSize. Each of these new threads usually runs only 1 or 2 tests.I found that by providing a predicate for saturated when creating the ForkJoinPool, and having it return true, it was possible to run all the tests with a much smaller maxPoolSize.
Currently it's not possible to control this parameter using a custom implementation of
ParallelExecutionConfiguration
.So I propose to add a method to the interface such as the following:
The
DefaultParallelExecutionConfiguration
would return null.The class
ForkJoinPoolHierarchicalTestExecutorService
would useconfiguration.getSaturatePredicate()
when creating theForkJoinPool
.The text was updated successfully, but these errors were encountered: