Hi Chris, It is indeed a good idea to create asynchronous versions of the engine server! Naoki has recently completed the migration from spray to Akka HTTP so you may want to base off from that instead. Let us know if we can help in any way.
I do not recall the exact reason anymore, but engine server was created almost 5 years ago, and I don’t remember whether spray could take futures natively as responses like Akka HTTP could now. Nowadays there shouldn’t be any reason to not provide asynchronous flavors of these APIs. Regards, Donald On Thu, Oct 11, 2018 at 3:20 PM Naoki Takezoe <[email protected]> wrote: > 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 <[email protected]>: > > > > > 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 > > > > -- > Naoki Takezoe >
