On 11/02/2015 22:43, Greg Wilkins wrote:
> On 12 February 2015 at 08:40, Mark Thomas <markt_at_apache.org
> <mailto: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?
No. I said Tomcat would only do this if either stream was closed. At
this point - as far as Tomcat in concerned - both streams are open.
Tomcat waits until the close message has been sent back to the client
and then it closes the streams and calls 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?
The way things are implemented, allDataRead is not currently triggered
in WebSocket for Tomcat and Tomcat never sees the -1 because it stops
reading the InputStream as soon as it has received a Close message. This
doesn't translate too well for the general case.
For the general case, I agree with your statement above.
Mark
> 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 <mailto: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.