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

[Chris Hegarty]

Looks fine.

-Chris.

On 09/06/16 11:54, Pavel Rappo wrote:
> Hi,
>
> Could you please review the following change for JDK-8157273?
>
> http://cr.openjdk.java.net/~prappo/8157273/webrev.01/
>
> This change addresses some WebSocket API refinements and enhancements from [1].
>
> Currently WebSocket API allows only one scheduled but not yet sent message (i.e.
> an outstanding send operation) at a time. This design was influenced by
> java.nio.channels.AsynchronousChannel:
>
>      * <p> Asynchronous channels are safe for use by multiple concurrent threads.
>      * Some channel implementations may support concurrent reading and writing, but
>      * may not allow more than one read and one write operation to be outstanding at
>      * any given time.
>
> Although it is both easy to understand and implement, this was found to not work
> well with WebSocket API.
>
> 1. In WebSocket API it's not always easily known (in some modes of operation)
> for an app when the previous send operation has completed. Thus maintaining a
> non-overlapping sends is a burden on the user.
>
> 2. In contract with AsynchronousChannel, WebSocket does not allow "short writes"
> (i.e. a situation when a Future returned by the send operation may complete
> normally after the message has been written only partially.)
> The CompletableFuture in WebSocket completes only after an error or when the
> whole message has been written. Therefore, there's no inherent risk in
> serializing sends in WebSocket.
> The result on the wire will always be some permutation of messages, and not
> their chunks.
>
> Thanks,
> -Pavel
>
> --------------------------------------------------------------------------------
> [1] https://bugs.openjdk.java.net/browse/JDK-8155621
>