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.
