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

[Christoph Läubrich <laeubi@xxxxxxxxxxxxxx>]

Am 26.10.2016 18:14, schrieb Simone Bordet:

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.
  

Just a short question so I get things right: If I do not dispatch myself won't the container dispatch always if I do not call complete() from the onTimeout? From the documentation of AsyncContext they mention:

"If none of the listeners called complete() or any of the dispatch() methods, perform an error dispatch with a status code equal to HttpServletResponse.SC_INTERNAL_SERVER_ERROR"

I'm not just sure what an error-dispatch mean, will only error handler be called or will my servlet be called first or only if no error handler is present?


Am 26.10.2016 18:24, schrieb Simone Bordet:

Hi,

On Wed, Oct 26, 2016 at 6:14 PM, Simone Bordet <sbordet@xxxxxxxxxxx> wrote:
  

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()).
    

Incidentally, this is why non-trivial applications don't use the
built-in timeout mechanism.
If the application times out and has to write a response content that
may block, the only option is to block.
With a custom timer, you can write asynchronously because you're not
restricted by having to call dispatch() or complete() from
onTimeout().

  

so you recommend to set the timeout to 0 and fire of an own Scheduler to actually timeout for any non trivial use-case? Sounds like a good workaround at least for my case since I already have a worker pool of threads.