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 > cases. > > 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 > them. > > 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. > > --Rafael > >
