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.bor...@gmail.com> wrote: > > Hi, > > On Tue, Jun 14, 2016 at 1:26 PM, Pavel Rappo <pavel.ra...@oracle.com> wrote: >> >>> On 13 Jun 2016, at 12:14, Simone Bordet <simone.bor...@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
