RFR JDK-8157273: Simplify outgoing messages queueing policy in WebSocket API

[Simone Bordet]

Hi,

On Mon, Jun 13, 2016 at 3:40 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>
>> On 13 Jun 2016, at 12:14, Simone Bordet <simone.bordet at gmail.com> wrote:
>>
>> Close should definitely *not* "jump ahead of the queue", it should be
>> sent after queued stuff has been sent.
>
> Why is that?

Because contrary to ping, the specification does not say "as soon as
possible" but:

"An endpoint MAY delay sending a Close frame until its current message is
sent (for instance, if the majority of a fragmented message is
already sent, an endpoint MAY send the remaining fragments before
sending a Close frame)."

> Shouldn't we treat this as an implementation specific detail? I
> mean Close, Ping and Pong are control messages. They are differ from Text and
> Binary ones.
>
> If we specify this straight away, we're closing the ability for Close to behave
> like this. Are you sure this kind of Close behaviour is *never* needed?
> Meanwhile it's easy to note in the API that if one wants to *force* order then
> sendClose should be chained through CSs. It should be easy, especially taking
> into account Close is the last message sent by a client.

True :)

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz