Last image caching (was Re: Now that M3 is complete...)

[Gordon Sim <gs...@redhat.com>]

Robert Greig wrote:
> I think it would be interesting to play this out in one of the most
> common use cases - equity prices. So assume that we have a topic
> hierarchy that people subscribe to e.g. stocks.nasdaq, stocks.ftse
> etc. Messages are published with routing keys like stocks.nasdaq.MSFT
> etc. Consumers subscribe to e.g. stocks.nasdaq.*
> 
> With a single replay queue, it would seem to me that it would be
> necessary to store the routing key used to publish the message (i.e.
> this is some special queue). Then when a new consumer subscribes, the
> replay queue is given the routing key and filters using some variant
> of a message selector to get the relevant messages.

Yes, my thought was that we could support this by using another (as yet 
unimplemented) feature, whereby messages with a particular value for the 
routing_key (or indeed any other property) would 'overwrite' any queued 
message with the same value.

I.e. the queue would always hold the last message sent matching a 
particular criteria.

However, perhaps thats overkill...

> I can see you could do it with multiple replay queues (e.g. one per
> routing key) which would mean you could use standard queues and avoid
> any kind of selector, pushing that bit into the exchange.
> 
> I don't think what I was thinking about was too different, I just
> thought that since the exchange had access to the routing key it would
> be quite easy to cache a message keyed on the routing key.

The simplicity of that is certainly attractive. I need to think some 
more and am keen to hear any/all thoughts and ideas on this.