[rabbitmq-discuss] Message Aggregating Queue

Tue May 3 12:11:13 BST 2011

On 28/04/11 13:54, Jason Zaugg wrote:
> The Last Value Caching Exchange seems to solve a slightly different
> problem (although one that we also have!). If I understand it, a queue
> attached to the LVC exchange would receive *every* newly delivered
> message, regardless of how fast it is able to process them.
Indeed. Maintaining the map at the queue level prevents the consumer 
getting overwhelmed with messages, which is kind of the point last-value 
in the first place. E.g. you may have a stock ticker app which only 
updates every second. It doesn't want to be flooded by millions of ticks 
it can't handle.

LVC exchange seems to be handling a somewhat different use-case 
sometimes known as "value + updates", where you're interested in syncing 
with some state machine (i.e. obtain current state), and also interested 
in getting all updates on that state from then on, so you can maintain a 
replica of that state machine. That's a common and valid use case, but 
not the same as the last-value queue case.

If you were so inclined, you could transform the "value+updates" case 
into the "last-value-queue" case by taking the  values+updates and 
maintaining a map yourself on the client-side to weed out "old" entries 
(as someone else mentioned), but this is a) extra work for you to do b) 
burns lots of bandwidth + cpu in sending unwanted messages to the 
client, and c) your client may still not be able to keep up with the 
firehose anyway.