On 17/02/2015 18:05, Shing Wai Chan wrote:
>
>
> On 2/15/15, 6:42 PM, Stuart Douglas wrote:
>> ----- Original Message -----
>>> From: "Mark Thomas"<markt_at_apache.org>
>>> To: jsr369-experts_at_servlet-spec.java.net
>>> Sent: Thursday, 12 February, 2015 5:40:14 AM
>>> Subject: [servlet-spec users] [jsr369-experts] Re: Upgrade is done?
>>>
>>> On 11/02/2015 05:08, Greg Wilkins wrote:
>>>>
>>>> All,
>>>>
>>>> Jetty currently doesn't implement the standard upgrade mechanism and
>>>> I'm
>>>> currently looking to fix that. The spec says:
>>>>
>>>> When the upgrade processing is done, HttpUpgradeHandler.destroy
>>>> will
>>>> be invoked.
>>>>
>>>> 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().
>> In Undertow we will not call destroy() until a connection is fully
>> closed.
> +1. This agrees with the javadoc: It is called when the client is
> disconnected.
No arguments here. We have got away with the current implementation to
date but I am in the progress of fixing it.
Mark
>
> Shing Wai Chan
>>
>> The idea behind upgrade is to allow the use of arbitrary protocols
>> over what is basically a raw TCP connection, and destroying the
>> connection once it becomes half closed does not match TCP semantics.
>>
>> There are some protocols that rely on being able to send data after
>> reading -1, and it will not be possible to implement these if we say
>> the connection has to be destroyed once one side is closed.
>>
>>>> I also note that the spec says async IO can be used, so I assume that
>>>> means that startAsync must be called before returning after the
>>>> request.upgrade call?
>>> Tomcat took that to mean that you could set a ReadListener and a
>>> WriteListener on the Streams if you wanted to use non-blocking.
>> We also implemented this the same way (no startAsync required).
>>
>>> The main reasons for the above choices were:
>>> - the choices looked to be consistent with the spec
>>> - the choices worked for Tomcat's WebSocket on top of Servlet API impl
>> I don't see how the 'closing one stream closes both' behaviour is
>> consistent with the spec?
>>
>> Stuart
>>
>>
>>> Mark
>>>
>>>