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

[Chris Hegarty]

Following this discussion, I think the point is that the size of the send queue
is an implementation detail, and therefore cannot be replied upon ( another 
implementation could have a smaller upper bound ). Having a method on
builder similar to the sketch below, may address this concern.

  /**
   * Sets the maximum number of outstanding messages.
   *
   * <p> By default there is no upper bound on the number of outstanding
   * messages. If this method is invoked, then an attempt to send a message, 
   * where there are ‘limit’ number of outstanding messages in the send queue
   * will result in an Exception…..
   */
  setMaxSendMessages(int limit)

If this was added, then the upper bound could be relied upon. This, somewhat,
simplifies the programming model. The CF’s returned from the sendXXX 
methods can be used, or not, if notification of the actual send is required, or
when determining if the resources associated with the send are “reusable”,
i.e. no longer required by the implementation.  I think this simpler programming 
model, not using CF's will be most common, but it doesn’t get in the way of a
more sophisticated advanced usage.

-Chris.

> On 14 Jun 2016, at 13:36, Simone Bordet <simone.bordet at gmail.com> wrote:
> 
> Hi,
> 
> On Tue, Jun 14, 2016 at 1:26 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>> 
>>> On 13 Jun 2016, at 12:14, Simone Bordet <simone.bordet at gmail.com> wrote:
>>> 
>>>> Should the application be in charge of chopping outgoing messages in chunks in
>>>> order to provide better responsiveness when needed?
>>> 
>>> Not sure what you mean here.
>> 
>> What I meant here was that Ping's latency doesn't depend on some kind of magic.
>> Implementation and/or application has to chop messages/fragments into more
>> fragments of a certain size *beforehand* to provide more places a control frame
>> can be injected to.
>> 
>> If a giant message/frame has been being sent, there's nothing can be done to
>> interject a control message quickly.
>> 
>> If we say a partial message corresponds to 1+ frames on a wire than both
>> implementation and the application can contribute better responsiveness. If we
>> say a partial message corresponds to exactly 1 frame, than all the burden of
>> chopping is on the application. In this case the responsiveness is independent
>> from an implementation.
> 
> That is again a semantic problem, but I think this one is simple: the
> implementation cannot guarantee that one API call correspond to one
> frame.
> There are, for example, fragmentation extensions that
> fragment/reassemble frames into smaller/larger units, so it that
> extension is in place the guarantee is lost.
> Same for gzipping. I know that the current draft does not support
> extensions, but a 1-to-1 semantic is not something you want to bind to
> when in future you may add extensions.
> 
> -- 
> 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