Got it. Thanks a lot, Simone! On Fri, Jul 26, 2019 at 2:58 PM Simone Bordet <[email protected]> wrote:
> Hi, > > On Fri, Jul 26, 2019 at 10:53 AM Abhirama <[email protected]> wrote: > > > > I see. But then if we're using Jetty's default thread pool for async > processing as well, aren't we taking away a thread from the pool which > Jetty could've used for accepting requests? > > Correct. > > > If yes, what's the benefit of using async processing? > > if your application does async *blocking* processing, then you have 2 > choices: > 1. Use AsyncContext.start() and risk to exhaust the Jetty thread pool > (so this is identical to sync blocking processing). However, Jetty has > components that may help dealing with this situation (e.g. > LowResourceMonitor, QoSFilter, etc.) and apply backpressure to > clients. > 2. Use another Executor for your async blocking tasks (which has the > benefit that Jetty remains responsive, but you may queue up infinitely > on the executor because you're not applying backpressure (or you have > to manually tell Jetty to apply backpressure). > > The real solution is to do async *non-blocking* processing, and at > that point using the Jetty thread pool or another Executor is the > same, as the tasks will never block. > > The benefit of async processing only appears (and it's huge) when you > are non-blocking. > > -- > Simone Bordet > ---- > http://cometd.org > http://webtide.com > Developer advice, training, services and support > from the Jetty & CometD experts. > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
