Am 26.10.2016 18:14, schrieb Simone Bordet:
Hi,
On Wed, Oct 26, 2016 at 5:39 PM, Christoph Läubrich
<[email protected]> 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()|
<https://docs.oracle.com/javaee/6/api/javax/servlet/AsyncContext.html#complete%28%29>
or any of the |dispatch()|
<https://docs.oracle.com/javaee/6/api/javax/servlet/AsyncContext.html#dispatch%28%29>
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<[email protected]> 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.
_______________________________________________
jetty-users mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
