Re: [jetty-users] Threading issue with AsyncListener.onTimeout

[Simone Bordet <sbordet@xxxxxxxxxxx>]

Hi,

On Wed, Oct 26, 2016 at 5:39 PM, Christoph Läubrich
<laeubi@xxxxxxxxxxxxxx> wrote:
> As I noticed that at least onComplete is dispatched to a qtp I think there
> is no much performance-hit in doing this for onTimeout because you either
> will dispatch to a qtp right after onTimeout (because the servlet is called
> again)

If you dispatch(), yes.

> or onComplete is called, so you can call onTimeout and dispatch to
> the servlet in a qtp, or cou can call ontimeout and then call onComplete in
> a qtp without a further context-switch, but maybe I missed something?

onTimeout() merely notifies the application that the timeout expired.
>From there you can call AsyncContext.complete() directly, and the
container will write the response headers asynchronously for you.
Otherwise, you have to block writing the content (because you cannot
return from onTimeout() without calling dispatch() or complete()).

> You are right that blocking is still bad, but there is a huge difference if
> you block for some time in one thread and hold off the whole world or if you
> block for some time in one thread from a pool out of hundreds of others and
> slow down for a while (if low on threads...).

Sure.
But the point is how much a container should do to shield itself from
"bad" applications.
There are so many ways to screw things that it's impossible to guard
against all of them.
So the assumption is that applications behave well, and they don't get
performance hits.

>>  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.
>
>
> Just wondering: What do you mean by "good" and "bad" applications? I can't
> find any hint that it is "bad" to do any other work beside setting some
> Request-Attribute or calling complete in onTimeout, beside that it is always
> a good idea to keep event-methods short.

"Bad" is when an application sits on a callback like onTimeout() doing
blocking I/O operations that can last a long time.

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