Oops, this was supposed to go to the list.
On Mon, Mar 4, 2013 at 11:56 AM, Rafael Schloming <r...@alum.mit.edu> wrote:
> On Thu, Feb 28, 2013 at 12:55 PM, Alan Conway <acon...@redhat.com> wrote:
>> I think this is a common case:
>> (1a) an app wants to receive and process messages indefinitely, but wants
>> the implementation to use a bounded buffer of N messages or B bytes to do
>> so. AKA "credit window" in AMQP 0.10 or "prefetch" in JMS.
>> I'm not familiar enough with Messenger yet to say whether that belongs in
>> the messenger API or in some other configuration, but I think it needs to
>> be a use case that is easy to set up. Agreed that ideally we would have a
>> dynamic flow control algorithm that can figure out the optimal credit
>> settings by itself, but until we do I suspect the simple "bounded buffer"
>> model will cover most cases, and doesn't require exposing the complexity of
>> the underlying flow control.
> This is an interesting scenario because while it's a common case, it's
> arguably not a truly general case. In fact it is an anti-pattern in some
> The problem this approach is that it depends on there being only a small
> penalty from using an oversized prefetch limit. Based on this assumption
> you can avoid computing the optimal prefetch amount and simply advise the
> user to statically assign a number large enough to guarantee in practice
> that there will always be messages sitting in the prefetch buffer. This
> works fine for a simple point to point scenario where the only cost is
> wasted memory on the client side for holding messages that didn't need to
> be prefetched in order to avoid stalling.
> Consider, however, what happens if you copy the point to point receiver
> and based on its code try to set up a job queue that load balances messages
> to competing consumers. Even a relatively small prefetch like 1024 can now
> result in pathological behaviour as your first consumer may well suck up
> all the messages in the queue and prevent other consumers from processing
> Now given that it is quite trivial to write message processing code that
> has no clue if it is running in a point to point vs load balanced
> environment, I think it would be unfortunate if our API forced users to
> make that code become specific to the topology in which it happens to be
> deployed. What this amounts to is that any number appearing in the API used
> by application code to fetch messages needs to actually have semantic
> meaning to the *application* and *not* the topology (e.g. the application
> is actually expecting N replies and no more).
> A possible consequence of this is that the messenger implementation needs
> to be smarter and track both round trip time and message processing time,
> however measuring these quantities isn't actually all that difficult or
> expensive, and if these numbers are known it is quite trivial to compute an
> optimal prefetch limit. Given this, I don't think there is really a good
> reason to make users guess at what an optimal value might be and I
> certainly wouldn't put it as part of the primary message retrieval API,
> rather as a tuning parameter for the internal algorithm.