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

[Simone Bordet]

Hi,

On Tue, Jun 14, 2016 at 6:15 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 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.

However, you still want to use the CFs for exception reporting.

BTW, this suggestion was ruled out by Pavel when I suggested it.
Not sure who overrules here :)

Thanks !

-- 
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