Hi, On Tue, Jun 14, 2016 at 6:15 PM, Chris Hegarty <chris.hega...@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
