[rabbitmq-discuss] Routing key match algorithms

[Michael Bridgen]

> The problem I see is that, if a consumer issues a regex as a pattern for
> a subscription, when a message gets published, how do I find out all the
> regexes I know about that match? Do I loop over all the consumers,
> asking each one if they match or not? Seems kind of inefficient.

Indeed.  Building an FSM with bindings as transitions states would be a 
start.  "Collecting" states after binding deletion is likely to be the 
tricky bit.

> Just wondering if this problem was known and passed over early on, and
> the */# mechanism used to get around this problem.

I suspect the */# mechanism was made to match JMS implementations, and I 
suspect those used it because it was fairly easy to implement and to 
grasp as a user.

Regular expressions are not tougher in kind than globbing, since they 
both describe regular languages.  They are more fiddly to implement however.

> I also thought about using some text indexing engine (a la lucene) to
> solve this problem, but if a message gets published with a specific
> routing key, you'd have to re-run the search attached to the consumers
> to get an updated list of messages that match a given regex. So there's
> no benefit from doing that either, so far as I can tell.

One approach to implementing topic matching is to keep something a bit 
like a reverse index: http://www.openamq.org/doc:fast-topic-matching

Vlad at Rabbit tried this among other techniques, and posted his results:
http://www.rabbitmq.com/blog/2010/09/14/very-fast-and-scalable-topic-routing-part-1/ 
and 
http://www.rabbitmq.com/blog/2011/03/28/very-fast-and-scalable-topic-routing-part-2/


mkb