On 12 February 2015 at 08:40, Mark Thomas <markt_at_apache.org> wrote:
> On 11/02/2015 05:08, Greg Wilkins wrote:
> > What does "is done" mean? Does it mean both input and output streams
> > have been closed?
>
> Tomcat took that to mean if either of those streams was closed. Tomcat
> ensures both streams are closed and then calls destroy().
>
Mark,
Thanks for the clarification, but I'm not sure how that can work for
websocket in all situations?
Consider the case that you receive a Close frame in a onDataAvailable
callback. The websocket spec requires you to write a Close frame in
response as soon as possible. So you try to write the close frame in reply
and have to call isReady() first before doing so. If isReady() returns
false, then that means a previous write of a frame has not yet completed
and a callback to onWritePossible() is scheduled. You should then return
from onDataAvailable.
You say that at this point, Tomcat will close the stream and call
destroy? But a close at this point will probably result in a RST that
will truncate the frame being sent and the close frame will never be sent
at all, thus breaking the websocket graceful shutdown?
Surely we need to wait until allDataRead() and ServletOutputStream.close()
have both been called before a destroy? I know that is a lot different to
other parts of the spec, but then we have a return from service or a call
to complete to unambiguously indicate the end of handling.
Sorry that these thoughts are several years late!
cheers
--
Greg Wilkins <gregw_at_intalio.com> @ Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com advice and support for jetty and cometd.