[rabbitmq-discuss] queue selection based on a 'feature list'

Wed Oct 30 15:29:12 GMT 2013

Emile,

Thanks for the reply.

I had considered this approach and could use this for initial testing, 
however the feature set that I am looking for is somewhat large and could 
expand, each time doubling the combinations. I think the end result will be 
creating an exchange plugin very similar to the topic exchange but where 
the '*' and '#' can also be used in the message routing keys. Using this 
wouldn't break any existing topic exchange usage but would allow messages 
to be crafted with 'I don't care', and if a trailing '#' was always used in 
the message, adding new features to the servers wouldn't break existing 
producers.

On Oct 30 2013, Emile Joubert wrote:

>On 30/10/13 13:54, Lawrence Freil wrote:
>
>> Is there a way to accomplish this with the current exchanges?
>
>There may be a way to approximate this with a topic exchange if you
>associate features with consumers rather than queues. You could create a
>queue for each combination of features and bind so that it received
>messages that require exactly those features.
>
>E.g. you could declare queues
>
>____, w___, _x___, __y_, ___z,
>wx__, ... , w__z, ..., wxyz.
>
>and bind them:
>
>____ with binding key _._._._
>w___ with binding key w._._._
>_x__ with binding key _.x._._
>__y_ with binding key _._.y._
>___z with binding key _._._.z
>...
>wx__ with binding key w.x._._
>w__z with binding key w._._.z
>...
>wxyz with binding key w.x.y.z
>
>Consumers can then consume from all queues that contain messages that
>demand a subset of the features offered by that consumer, e.g. a
>consumer that offers
>
>x and y consumes from ____ and _x__ and __y_ and _xy_
>only z  consumes from ____ and ___z
>w,x,y,z consumes from all queues
>
>Then if you publish a message with routing key _.x.y._ it will arrive at
>queue _xy_ and be sent to a consumer that is guaranteed to offer x and y.
>
>
>If the number of features is large or rapidly changing then this will
>become unmanageable. If the features are strictly associated with queues
>rather than consumers then it also won't work.
>
>
>
>-Emile
>
>
>
>
>
>

-- 
Lawrence Freil
lef at apago.com
770-619-1884