[jsr369-experts] Re: [servlet-spec users] Re: Upgrade is done?

From: Mark Thomas <markt_at_apache.org>
Date: Thu, 12 Feb 2015 12:28:14 +0000

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.


> 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.