[SERVLET_SPEC-44] Client close notification Created: 21/Aug/12  Updated: 10/Dec/13

Status: Reopened
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: jitu Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 14
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There is no notification event for client close.
Is it possible to add AsyncListener#onClose() when the client is disconnected ? This will be
useful for long running connections like server-sent events connection.

On the other hand, SE socket API itself doesn't provide that option. So there may be no way to get client close notification when there is no pending i/o.



 Comments   
Comment by Marek Potociar [ 23/Aug/12 ]

onDisconnect(...) would be a better name IMO. Also, if that's not possible due to the lack of JavaSE Socket API, should it be clarified that onError(...) could be used for that purpose?

Comment by Shing Wai Chan [ 08/Jan/13 ]

There is no way to know when the socket is closed from SE API.

Comment by jfarcand [ 24/Apr/13 ]

I disagree. Any NIO layer can detect when the underlying connection is getting closed. Look at Grizzly/Tomcat NIO/Netty, they all able to handle that case.

Comment by Shing Wai Chan [ 24/Apr/13 ]

java.nio.channels.Channel#isOpen tests whether or not the channel is open.
So, we will revisit the issue.

Comment by Mikhail Mazursky [ 19/Jul/13 ]

Because this feature is missing it is not possible to stop resource consuming computations on server if client disconnects. Please, see this ticket for example https://sourceforge.net/apps/trac/bigdata/ticket/694

Comment by rstoyanchev [ 10/Dec/13 ]

Adding a link to a discussion on Tomcat's user list.

Comment by rstoyanchev [ 10/Dec/13 ]

As one example of why this matters consider the SockJS protocol that provides HTTP fallback options for WebSocket.

The protocol does not define any client-side "close" frame. It expects the server will detect when the HTTP connection is closed and indeed a variety of server-side implementations in a range of languages (node, erlang, python, ruby) do.

A Java implementation – with Servlet 3 async for the long polling or HTTP streaming – however cannot detect when a client has gone away. This is a very fundamental, missing feature that puts Java Servlet-based implementations at a significant disadvantage.





[SERVLET_SPEC-119] Clarification of threading requirements of section 6.2.3 Created: 15/Dec/14  Updated: 19/Dec/14

Status: Reopened
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 4.0, 4.0-m01

Type: Improvement Priority: Minor
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 40 minutes
Original Estimate: Not Specified


 Description   

>>>>> On Sat, 06 Dec 2014 00:14:51 +0000, Mark Thomas <markt@apache.org> said:

MT> Hi,
MT> Section 6.2.3 includes the following text:

Spec> A Filter and the target servlet or resource at the end of the
Spec> filter chain must execute in the same invocation thread.

MT> As a result of a bug raised against Apache Tomcat [1] I am seeking
MT> clarification of the meaning of that sentence.
MT>
MT> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=57284



 Comments   
Comment by Ed Burns [ 15/Dec/14 ]

If the Filter wants to go async, allowing them to do so would be
consistent with that design intent. In the absence of further data, let
me suggest some alternate text for section 6.2.3.

Proposed623> When operating in synchronous mode, a Filter and the target
Proposed623> servlet or resource at the end of the filter chain must
Proposed623> execute in the same invocation thread. When operating in
Proposed623> asynchronous mode, a Filter and the target servlet or
Proposed623> resource at the end of the filter chain must execute on the
Proposed623> invocation thread to which control is handed when the
Proposed623> asynchronous processing commences.

Comment by Ed Burns [ 15/Dec/14 ]

Further input from Mark Thomas.

Comment by gregwilkins [ 16/Dec/14 ]

I'm not sure this one is sufficiently agreed to be closed.

I'm not sure what the new text means when it says "on the invocation thread to which control is handed when the asynchronous processing commences". Asynchronous processing may not have 1 thread in control, it may have many threads in control.

Currently I am not convinced that we should allow arbitrary threads to call FilterChain.doFilter or RequestDispatcher.forward. I don't think it has been established why the current spec text is not good. I also think that any such change needs to be very carefully reviewed against issues such:
+ what should the getContextPath getSErvletPath methods return? what about the race with the exiting container thread?
+ what about calls to ServletRequestListeners are called and if ThreadLocals can be used.

Can we reopen this one and discuss more on the list?

Comment by Ed Burns [ 18/Dec/14 ]

svn commit -m "Revert change for SERVLET_SPEC-119" filters.fm
Sending filters.fm
Transmitting file data .
Committed revision 103.





Generated at Sun Mar 29 08:24:24 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.