Provide more options to configure ForkJoinPoolHierarchicalTestExecutorService's ForkJoinPool

[tmirzoev]

I've recently encountered a problem similar to #1675 , but a bit worse: provided that all tests use Future.get() at some point and there's enough of them, a user can run into situation where tests start failing with RejectedExecutionException thrown by ForkJoinPool's tryCompensate() method.

This can be avoided by tuning the parameters of ForkJoinPool used in JUnit's ForkJoinPoolHierarchicalTestExecutorService - there are several ways,and I'm using custom ForkJoinWorkerThreadFactory implementation that keeps track of running workers.

The problem is, ForkJoinPoolHierarchicalTestExecutorService and other classes are not very open for such modifications.
I have no way to inject custon thread factory via config. I can not inject already created FJP at construction time, or override a constructor, due to how FJP creation is made in private method called in a constructor.
This goes even further: ForkJoinPoolHierarchicalTestExecutorService parses the configuration with DefaultParallelExecutionConfigurationStrategy.getStrategy() method which is package-private, and JupiterTestEngine has its own share of private methods and is final, so no overriding there.

This results in a situation, where in order to change one argument sent to FJP's constructor, I have to either:
a) provide my own implementations of HierarchicalTestExecutorService, TestEngine and some other classes, which is a bit ridiculous because of how I want to change literally one parameter.
b) copy JUnit's default implementations to my code and change that argument there, which is also not so good due to excessive code and the need to license the copied code under EPL-2.0
c) use Reflection API to modify ForkJoinPoolHierarchicalTestExecutorService at runtime, replacing its FJP, or changing FJP's i
internal variables. This is the most effective solution, but it is rather brittle due to all that reflection stuff.

The point is, is there any possibility for JUnit to provide more options to configure ForkJoinPoolHierarchicalTestExecutorService and its pool, or, at least, to make the API more open to subclassing and modification? I totally understand that these APIs can and will be unstable and experimental, but it could potentially improve using JUnit with any tests that rely on code using Future - like Java's new HTTP API that runs all http requests this way.

[marcphilipp]

Thanks for raising the issue! Would your custom ForkJoinWorkerThreadFactory implementation be a good default?

[tmirzoev]

Thank you for quick response!

Basically, my custom implementation checks if (pool.getPoolSize() <= targetParallelism) every time a new ForkJoinWorkerThread is requested, and returns a new thread only if its true, otherwise it returns null.
This limits the number of tests running concurrently strictly to requested parallelism level.

I've yet to see, if it causes any un-obvious problems in our tests, but for now it looks good enough a solution.
I can make a PR if this idea sits well with JUnit team.

[marcphilipp]

IIRC there's a reason a ForkJoinPool can use more threads than its configured parallelism, e.g. see managedBlock which we use for @ResourceLock. Thus, I don't think your solution would be applicable in general.

[tmirzoev]

Well, there is a certain possibility that this solution is not for everyone.

I've considered this problem a bit more, and looks like providing more options to configure the ForkJoinPool used by ForkJoinPoolHierarchicalTestExecutorService would be enough.

The ForkJoinPool constructor has parameters maxPoolSize and saturate, which could be configured to achieve the required effect.
These parameters, along with custom ThreadFactory could be injected at FJP constructor call using the customised ParallelExecutionConfiguration.
And if I'm correct, there is a mechanic in place to allow us to provide a custom config class here .

The problem is, at the moment the ParallelExecutionConfiguration interface does not support any way to provide the saturate lambda or Thread factory instance.

So, what I'm proposing is this:

1. extend the existing configuration with additional getters that return the current default values, like

 Predicate<? super ForkJoinPool> getSaturate(){return null;}

 ForkJoinWorkerThreadFactory getThreadFactory(){return new WorkerThreadFactory();}

2. Use these additional methods for obtaining the configuration values at ForkJoinPoolHierarchicalTestExecutorService's FJP creation.

This way, the behavior will remain mostly the same for existing users, and in the same time the FJP will become completely configurable.
The main problem I see here is in how the ParallelExecutionConfiguration and DefaultParallelExecutionConfiguration can become coupled with ForkJoinPoolHierarchicalTestExecutorService in, well, providing ForkJoinPool-specific values.
This is totally open to discussion.
A possible solution here could be creating ForkJoinPoolExecutionConfiguration interface/concrete implementation, that would extend/implement ParallelExecutionConfiguration and support the getters for additional values. This new configuration will then be used in ForkJoinPoolHierarchicalTestExecutorService.

As I've stated before, I can make a PR with a solution we'll agree upon.

[marcphilipp]

Tentatively slated for 5.8 M2 solely for the purpose of team discussion.

[marcphilipp]

Team decision: Add ForkJoinPoolExecutionConfiguration with the additional getters as described above and check for it in ForkJoinPoolHierarchicalTestExecutorService.

@tmirzoev Would you be interested in submitting a PR?