[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-users] Configuring a separate threadpool for async execution
|
Hi,
On Fri, Jul 26, 2019 at 10:53 AM Abhirama <abhirama@xxxxxxxxx> 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.
