java fork-join executor usage for db access

Question

The ForkJoinTask explicitly calls out "Subdividable tasks should also not perform blocking I/O ". It's primary aim is " computational tasks calculating pure functions or operating on purely isolated objects". My question is :-

1. Why design the ForkJoinTask to restrict blocking IO tasks?
2. What are the gotchas if i do implement a blocking IO task?
3. How come both spring and play frameworks, are full of examples using fork-join executors for DB calls?

In my scenario, a single request does two types of works, one of which is encryption, which pushes CPU core to 100% for 200 ms and second, few database calls. Any kind of static partitioning such as 6 threads for encryption and 2 threads for blocking IO, will not provide optimal usage of the CPU. Hence, having a fork-join executor, with certain level of over provisioning in number of threads over total CPU count, coupled with work stealing, would ensure better usage of CPU resources.

Is my above assumption and understanding around forkjoin executor correct and if not, please point me towards the gap.

Answer 1

Why design the ForkJoinTask to restrict blocking IO tasks?

underlying the fork join pool is shared amount of threads, if there's some IO work blocking on those threads, then less threads for CPU intensive work. other none blocking work will starve.

What are the gotchas if i do implement a blocking IO task?

typically, FJPool allocated thread about the number of processors. so if you do have to use IO blocking on threads, make sure you allocate enough threads for your other tasks.

you can also iso late your IO work on dedicated threads that is not shared with FJ pool. but you call blocking IO, your thread blocks and get scheduled for other task until unblocked

How come both spring and play frameworks, are full of examples using fork-join executors for DB calls?

play is no different. they use dedicated pools for IO task, so other task won't suffer.

Answer 2

The Framework does not restrict any type of processing. It is not recommended to do blocking, etc. I wrote a critique about this framework years ago, here is the point on the recommendations. This was for the Java7 version but it is still applicable for Java8.

Blocking is not fatal, sprint and play block and they work just fine. You need to be careful when using Java8 since there is a default common-fork/join pool and tying up threads there may have consequences for other users. You could always define your own f/j pool with the additional overhead, but at least you wouldn't interfere with others using the common pool.

Your scenario doesn't look bad. You're not waiting for replies from the internet. Give it a try. If you run into difficulty with stalling threads, look into the ForkJoinPool.ManagedBlocker interface. Using that interface informs the f/j pool that you are doing blocking calls and the framework will create compensation threads.