2008/9/9 Gordon Sim <[EMAIL PROTECTED]>: > I haven't yet thought about it in sufficient detail, but I was imagining > allowing a 'replay queue' to be attached to an exchange instance (of any of > the existing types), and in bind requests for that exchange allowing clients > to ask that the queue they are binding first be populated with messages from > that replay queue (synchronised w.r.t. the incoming message stream so > nothing is lost). > > The replay queue could then have policies on it restricting the number of > messages it retains etc. In the simple case it might just hold a single > message, but it could hold more than that if required.
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. 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. That does assume a single message per routing key (which fits the stock price use case but I can see that multiple values per routing key may be useful). RG
