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
>