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
