You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently AsyncListener.onTimeout() is executed in a Thread named like Scheduler-2108649164 for example. All other event methods are executed in the qtp-threads.
This can easily lead to strange problems (see #517) and stopping of other onTimeout events at all.
Simone Bordet mentioned that this might hit performance for "Completely asynchronous applications that behave correctly" but I think the danger of blocking the whole server outweight this because of the following reasons:
You won't exspect in a multi-threaded server with a dedicated thread pool for work that there is work done outside in a magic thread since this is also never mentioned (like AWT-Thread)
Timeouts are in some use-case a key feature for function (e.g. Long-Polling) or some kind of keep the server running (canceling to long running task, QoS) and thus should work under all circumstances!
If you can't do much more in AsyncListener.onTimeout() than setting some variables in the request and either complete or dispatch you effectively have the penalty of a context switch already (becuase you must then redispatch to the servlet to do the hard work), at least as AsyncListener.onComplete() is ALWAYS called in a qtp-thread after wards, so if you wan't to avoid further context switch one could dispatch AsyncListener.onTimeout to a qtp-thread and then call AsyncListener.onComplete() right after that in the same thread in case of completion, or first do the dispatch that would happen if listener does not call complete.
As a last resort there might be a configuration option to switch this behaviour off if really desired.
The text was updated successfully, but these errors were encountered:
This is related to news-post https://dev.eclipse.org/mhonarc/lists/jetty-users/msg07333.html and issue #1036
Currently AsyncListener.onTimeout() is executed in a Thread named like Scheduler-2108649164 for example. All other event methods are executed in the qtp-threads.
This can easily lead to strange problems (see #517) and stopping of other onTimeout events at all.
Simone Bordet mentioned that this might hit performance for "Completely asynchronous applications that behave correctly" but I think the danger of blocking the whole server outweight this because of the following reasons:
As a last resort there might be a configuration option to switch this behaviour off if really desired.
The text was updated successfully, but these errors were encountered: