Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Threading issue with AsyncListener.onTimeout 
Hi,

On Sun, Oct 23, 2016 at 8:11 AM, Christoph Läubrich
<laeubi@xxxxxxxxxxxxxx> wrote:
> Jetty version: 9.3.8, Java Version 1.8.0_73
>
> I noticed that the .onTimeout-Method is executed in a Thread called
> Scheduler-<some number> instead of the qtp-threads other method
> (onStart/onComplete) are called.
> Since it seems there are only a small number of Scheduler Threads (in my
> installation I found that there seem one per connector + one other) if some
> work blocks in onTimeout the server gets unresponsive at least in respect to
> other timout events.

Right, but it is only possible to move the problem somewhere else.

> Since I have not found much about the jetty Scheduler-Threads (only that
> there is some kind of Scheduler-Service) I'd liek to ask:
>  - What are they used for and how many of them would one expect?

Mostly async timeouts and idle timeouts.
The scheduler can be configured when creating the ServerConnector.
The default uses a ScheduledExecutor with 1 thread.

>  - Can I configure the Number of Threads available, maybe with another
> Threadpool?

Yes, you need to customize the creation of the ServerConnector.

>  - Is it desired that onTimeout is executed in this (spare) Threads?
>  - If yes why is it not executed in the qtp like other event methods?

Completely asynchronous applications that behave correctly will get a
performance hit if we dispatch the call to onTimeout() to another
thread.
The implicit contract is that the application should behave correctly.
The current behavior is by design, and yes it's a tradeoff where good
applications will not get a performance hit, but bad applications may
hung the scheduled activities of the server.
We currently don't have an option to configure this behavior, but
perhaps we should.
Can you please file an issue ?

> I tried to force the work back to the qtp-thread by using:
>
>     event.getAsyncContext().getRequest().setAttribute("Timeout", true);
>     event.getAsyncContext().dispatch();
>
> in the onTimeout. But this only calls onComplete on my listener and never
> reaches my servlet again.

Your Servlet should be invoked again, we test this (and CometD is
entirely based on this working as expected).

If it does not, then either you have some configuration that prevents
it, or something else happens.

However, yes that would be a correct way to handle the situation where
you need to perform some blocking task after onTimeout(): dispatch
again, with some application flag to distinguish in the Servlet
whether you are in for a normal request or for a timeout re-dispatch.

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.

Back to the top