jsr369-experts@servlet-spec.java.net

[jsr369-experts] Re: [servlet-spec users] Request/Connection cancellation

From: Stuart Douglas <sdouglas_at_redhat.com>
Date: Sat, 17 Oct 2015 08:38:25 -0400 (EDT)

This seems reasonable, but we should probably include some kind of thread safety warning in the docs. The listener will be invoked by a different thread to the one that is currently processing, so the end user must take care to make sure the listener/processing code is thread safe.

I am also not convinced that ServletRequestListener is the best place for this. Likely only specific long running requests will need this functionality, and I think that is may make more sense for them to explicitly register a listener with the request.

Stuart

----- Original Message -----
> From: "Greg Wilkins" <gregw_at_webtide.com>
> To: jsr369-experts_at_servlet-spec.java.net
> Sent: Thursday, 15 October, 2015 1:29:46 AM
> Subject: [servlet-spec users] [jsr369-experts] Request/Connection cancellation
>
> I think there is some more HTTP2 features we should consider for the 4.0
> release.
>
> Unlike HTTP/1 it is possible for a HTTP/2 server to know if a connection
> has failed or if an individual stream has been reset before normal
> completion. This gives the possibility of adding listeners that can
> inform an application that their transport is no longer functional.
>
> Typically this would be useful if an application has dispatched an
> expensive and/or long running request handling process. With HTTP/1
> servers, it is not generally possible to know if the connection has been
> closed without actually attempting IO on it, so even if a client has long
> ago closed the connection, the first that the expensive/long request
> handler will know about it is when it completes and attempts to write the
> response.
>
> With HTTP/2, the connection is always IO active (as it is multiplexed), so
> any connection failures will be hungrily discovered with a read
> IOException. There are also explicit frames available to allow a
> particular stream to be reset.
>
> Thus there is now scope to provide a listener API that will be called if
> either a connection or request failure is detected.
>
> First quick thought for how this could be done would be to add a method on
> ServletRequestListener:
>
> default void requestCancelled(ServletRequestEvent sre) {}
>
> This call would have no affect on the normal request lifecycle and would be
> purely a notification that the underlying transport has been
> closed/cancelled/failed/shutdown. It would be up to the application to
> decide what (if anything) can be done about that.
>
> HTTP/1 containers would be free to make a best effort attempt to call this
> listener when appropriate, but typically this would only be possible in
> catastrophic situations (or else the server is exposed to DOS attacks by
> reading and buffering in order to seek IOExceptions).
>
> Thoughts?
>
> --
> Greg Wilkins <gregw@webtide.com> CTO http://webtide.com
>