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

[Pavel Rappo]

> On 13 Jun 2016, at 14:45, Simone Bordet <simone.bordet at gmail.com> wrote:
> 
> 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)."

This should be read in context :p

   If an endpoint receives a Close frame and did not previously send a
   Close frame, the endpoint MUST send a Close frame in response.  (When
   sending a Close frame in response, the endpoint typically echos the
   status code it received.)  It SHOULD do so as soon as practical. 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).

I think it's more about reciprocated Close rather than unsolicited.

Overall I'm thinking of pushing the change, with the disclaimer that in future
it doesn't stop us from accepting a custom queue in the builder. So
1-outstanding write policy could be enforced by the implementation.