The use-case that I know of is for servlets that are performing actions
other than reading/writing from the request/response. Thus they are unable
to read -1 or have not called isReady() to be able to receive an onError
callback.
Note that with HTTP/1 in many languages/OS's it is not actually possible to
detect EOF and/or errors without actually attempting an IO operation, so
the lack of an onClose reflected the impossibility of implementation.
However, with HTTP/2, the connection is always being read, so the closer of
an individual stream or the entire connection can be detected and would be
a very useful event for some applications to reduce their resource
allocation to closed connection. Note that with pushed resources that are
already in a client cache, it will be usual for a response stream to be
started and then aborted.
regards
On 7 March 2017 at 08:05, Rossen Stoyanchev <rstoyanchev_at_pivotal.io> wrote:
> Admittedly I'm no expert on how the notification can be implemented but
> RFC 7230 section 6.5 has this:
>
> A client or server that wishes to time out SHOULD issue a graceful
> close on the connection. Implementations SHOULD constantly monitor
> open connections for a received closure signal and respond to it as
> appropriate, since prompt closure of both sides of a connection
> enables allocated system resources to be reclaimed.
>
> Also with Netty (I'm on Linux/epoll) when a client goes away a
> "channelInactive" event fires immediately.
>
>
> On Mon, Mar 6, 2017 at 2:30 PM, Stuart Douglas <sdouglas_at_redhat.com>
> wrote:
>
>> I don't really see how this is possible or really required. Looking at
>> the JIRA it looks like there are a couple of use cases:
>>
>> - One way protocols such as SSE
>> - Two way protocols such as SockJS
>>
>> For a two way protocol being implemented in an async manner a close
>> from the client side will result in the read listener being notified
>> and read returning -1, which tells you that the client has closed the
>> socket, so in this case you already get a close notification.
>>
>> For one way protocols the client has generally already closed their
>> side of the socket, so the only way to detect that they have gone away
>> is when a write fails. There is no notification that we receive, and
>> depending on if the close was clean or not the TCP stack may not even
>> be aware they have gone away until there is a failure to send.
>>
>> IMHO there is not really anything we can do here.
>>
>> Stuart
>>
>>
>>
>>
>> On Tue, Mar 7, 2017 at 2:30 AM, Rossen Stoyanchev
>> <rstoyanchev_at_pivotal.io> wrote:
>> > hi,
>> >
>> > Are there plans to address [1] for Servlet 4, if not could it be
>> considered?
>> >
>> > It is the most voted issue and one that's pretty important for the async
>> > support. Typically it comes up when sending events with potential lag in
>> > between, e.g. SSE, WebSocket fallbacks, etc. The server side does not
>> find
>> > the connection is closed until the write for the next event fails.
>> >
>> > The problem can be alleviated if a server-to-client heartbeat mechanism.
>> > However that's not always readily available such as with SSE.
>> >
>> > Rossen
>> >
>> > [1] https://java.net/jira/browse/SERVLET_SPEC-44
>>
>
>
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com