[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-users] Threading issue with AsyncListener.onTimeout
|
Thanks for the clarification,
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.
it seems I messed something up in my inital setup, checking with a
test-case the request gets dispatched to the servlet, even if I do not
call dispatch at all.
Beside this I filed an issue
(https://github.com/eclipse/jetty.project/issues/1037) as a
discussion/request for improvement for the threading behavior.
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) 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?
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...).
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.
