Re: [jboss-as7-dev] JBossWeb does incorrect async timeout behavior?
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