8:01 a.m.
Both JBoss Web and Jetty 8.1 seem to do the same thing:
If you have suspended an HTTP request using request.suspend(100) and the
timeout is reached, they both seem to retry the request rather than
throwing an error code.
The javadoc for AsyncContext says otherwise though:
In the event that an asynchronous operation has timed out, the container
must run through these steps:
Invoke, at their onTimeout method, all AsyncListener instances
registered with the ServletRequest on which the asynchronous operation
was initiated.
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.
If no matching error page was found, or the error page did not call
complete() or any of the dispatch() methods, call complete().
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:10 a.m.
Bah, nevermind...internal JBossWeb timeout was just running slower than
the value I passed to suspend.
On 6/29/12 9:01 AM, Bill Burke wrote:
Both JBoss Web and Jetty 8.1 seem to do the same thing:
If you have suspended an HTTP request using request.suspend(100) and the
timeout is reached, they both seem to retry the request rather than
throwing an error code.
The javadoc for AsyncContext says otherwise though:
In the event that an asynchronous operation has timed out, the container
must run through these steps:
Invoke, at their onTimeout method, all AsyncListener instances
registered with the ServletRequest on which the asynchronous operation
was initiated.
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.
If no matching error page was found, or the error page did not call
complete() or any of the dispatch() methods, call complete().
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:09 a.m.
On Fri, 2012-06-29 at 09:10 -0400, Bill Burke wrote:
Bah, nevermind...internal JBossWeb timeout was just running slower
than
the value I passed to suspend.
Ah ok. I never believed IO related timeouts need a precise resolution
and so they are not checked very often (only once every 5s). So they
should not be used in place of a timer. The 5s is not configurable, but
it could be.
Since this is supposed to handle a large number of connections, checking
the timeout of each connection all the time is obviously costly. Unless
a more complex structure is used (ordered per timeout time), but then it
would be costly to update it too. Or timers could be used if it is
efficient (I doubt it).
On 6/29/12 9:01 AM, Bill Burke wrote:
> Both JBoss Web and Jetty 8.1 seem to do the same thing:
>
> If you have suspended an HTTP request using request.suspend(100) and the
> timeout is reached, they both seem to retry the request rather than
> throwing an error code.
>
> The javadoc for AsyncContext says otherwise though:
>
> In the event that an asynchronous operation has timed out, the container
> must run through these steps:
>
> Invoke, at their onTimeout method, all AsyncListener instances
> registered with the ServletRequest on which the asynchronous operation
> was initiated.
> 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.
> If no matching error page was found, or the error page did not call
> complete() or any of the dispatch() methods, call complete().
>
>
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
9:23 a.m.
On 6/29/12 10:09 AM, Remy Maucherat wrote:
On Fri, 2012-06-29 at 09:10 -0400, Bill Burke wrote:
> Bah, nevermind...internal JBossWeb timeout was just running slower than
> the value I passed to suspend.
Ah ok. I never believed IO related timeouts need a precise resolution
and so they are not checked very often (only once every 5s). So they
should not be used in place of a timer. The 5s is not configurable, but
it could be.
Ya I agree and that's fine. I was just testing my jax-rs 2.0 async
support: timeout test plus trying to resume after a timeout. My sleeps
were just too short.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4332
days inactive
4332
days old
3 comments
2 participants
participants (2)
-
Bill Burke -
Remy Maucherat