jeudi 26 février 2015

java fork-join executor usage for db access



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.




Aucun commentaire:

Enregistrer un commentaire