Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't execute AsyncListener.onTimeout events in spare Scheduler-Thread #1037

Closed
laeubi opened this issue Oct 26, 2016 · 1 comment
Closed
Assignees

Comments

@laeubi
Copy link
Contributor

laeubi commented Oct 26, 2016

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:

  1. 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)
  2. 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!
  3. 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.

@sbordet
Copy link
Contributor

sbordet commented Oct 27, 2016

I convinced myself, and also discussed this with the team, that is better we call onTimeout() from a pooled thread, rather than the scheduler thread.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants