Hi Chris, I think current LEventStore's blocking methods should take ExecutionContext as an implicit parameter and Future version of methods should be provided. I don't know why they aren't. Is there anyone who knows reason for the current LEventStore API?
At the moment, you can consider to use LEvent directly to access Future version of methods as a workaround. 2018年10月11日(木) 23:05 Chris Wewerka <chris.wewe...@gmail.com>: > > 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 <gyar...@griddynamics.com> 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 -- Naoki Takezoe
