[rabbitmq-discuss] queue selection based on a 'feature list'
Lawrence Freil
lef at apago.com
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
More information about the rabbitmq-discuss
mailing list