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