Check for Common FJP Having Zero Threads #131
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This branch addresses the case where the common ForkJoinPool (FJP) has zero threads. This can occur with
-Djava.util.concurrent.ForkJoinPool.common.parallelism=0
, or in certain Kubernetes environments on certain versions of the JDK.When this condition occurs, the result is brutal for our users. The system will simply hang without reporting any error. A jstack dump won't show any threads blocked either. The user will have no indication about it is causing the issue and how to fix it.
The fix will have Oracle R2DBC fallback to a single threaded ForkJoinPool if the common pool potentially has zero threads. Unfortunately, there is no simple way to distinguish between common FJP that has 1 thread or 0 threads. The
getParallelism
andgetCommonPoolParallelism
methods both return 1 when the FJP has 0 threads. They also return 1 when the FJP has 1 thread. So the fix will fall back to a single threaded FJP in either case.Revised Fix:
Oracle R2DBC will only check for common.parallelism=0. This is the only valid way to have zero threads in the common pool.
Oracle R2DBC will not check for getCommonPoolParallelism()==1. That fix is only valuable when the JDK has a defect. The fix detract value for users who aren't using a defective JDK, as it unnecessarily allocates an additional thread.