Thanks George, good to hear that! Today I did a test by raising the bar for the max allowed threads in the "standard"
scala.concurrent.ExecutionContext.Implicits.global I did this before calling "pio deploy" by adding export JAVA_OPTS="$JAVA_OPTS -Dscala.concurrent.context.numThreads=1000 -Dscala.concurrent.context.maxThreads=1000" Now we do see much more CPU usage by elasticsearch. So it seems that the QueryServer by using the standard thread pool bounded to the available processors acted like a dam. By setting the above values we now have sth. like a traditional Java JEE or Spring application which blocks thread because of synchronous calls and creates new threads if there is demand (requests) for it. So this is far from being a good solution. Going full async/reactive is still the way to go in my opinion. Cheers Chris On Thu, 11 Oct 2018 at 14:07, George Yarish <[email protected]> wrote: > > Hi Chris, > > I'm not a contributor of the predictionio. But want to mention we also > quite interested in that changes in my company. > We often develop some custom pio engines, and it doesn't look right to me > to use Await.result with non-blocking api. > Totally agree with your point. > Thanks for the question! > > George >
