[rabbitmq-discuss] Message Aggregating Queue

[Alvaro Videla]

Jason,

What I understood yesterday is that you will have one queue for UBS, another queue for Credit Suisse and so on. You mentioned something about unique identifiers per tick type which could be used as routing keys, then having a direct exchange bound to all those queues based on the tick type. My custom queue proposal is based on such assumptions.

-Alvaro


On Apr 28, 2011, at 3:01 PM, Alexis Richardson wrote:

> Jason
> 
> On Thu, Apr 28, 2011 at 1:54 PM, Jason Zaugg <jzaugg at gmail.com> wrote:
>> Thanks for the great ideas and discussion so far!
>> 
>> Another requirement I should make explicit: we have a single consumer
>> reading the stream of price updates for all stocks; and it should
>> process them the order. That is, we don't want to 'UBS' to move to the
>> back of the queue if it updates before the previous message is
>> processed. So a data structure like as LinkedHashMap would be needed
>> for the custom queue proposed by Alvaro.
> 
> I'm confused.  Would this stream contain exactly one price per ticker
> symbol?  If so then why does it have to be a stream and not a set?  If
> it must be a stream with multiple values per ticker, then just use
> direct exchanges and one queue for the full stream.
> 
> 
>> 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.
> 
> Correct.  The LVC exchange is just a map from ticker to last value.
> It does not affect delivery of subsequent messages.
> 
> Are you sure you wouldn't be better off using a cache?
> 
>> In
>> addition, as soon as the queue is bound the the exchange, it would
>> receive the last value for each routing key.
> 
> Correct.
> 
> alexis

Sent form my Nokia 1100