Hi Nathan,
> What are the scenarios where it is important to have a ForkJoinPool that uses pooled threads from the container rather than the application instantiating its own ForkJoinPool as currently possible?
> Any other reasons for wanting it to be managed by the container? Given ForkJoinPool is intended for high performance, would the ability to run with the thread context of the submitter even be desirable?
Thanks for raising this question and asking for feedback.
In my opinion the definite answer to your question is “YES”! The reason there is a strong desire for a manageable ForkJoinPool is the same reason we needed JSR236.
One example for a value that for sure needs to be manageable is the “parallelism” of a certain ForkJoinPool! This is defaulted to “java.lang.Runtime#availableProcessors” which might be fine at the first glance as it is environment specific but can get you into trouble in cases where
- the value is not detected correctly because the application server is run in a shared/ virtual machine
- there are multiple thread-pools using this value to calculate their parallelism/ number of threads
- there are multiple JVMs on one host/ machine which rely on this value
Nowadays where people try different levels of virtualisation, we should really provide a way to override such “auto-discovered” values.
Until we don’t get this managed, the usage of JDK8 Streams API’s “.parallelStream()” is also risky in those environments. Therefore IMO we should really tackle that topic soon, but I’m also looking forward to the thoughts of others.
Best regards
Alex
---
Alexander Heusingfeld, alexander.heusingfeld@innoq.com <mailto:alexander.heusingfeld@innoq.com>, http://www.innoq.com <http://www.innoq.com/>
innoQ Deutschland GmbH, Krischerstr. 100, 40789 Monheim, Germany