[rabbitmq-discuss] queue selection based on a 'feature list'
videlalvaro at gmail.com
Sat Nov 2 08:57:43 GMT 2013
I've created a "reverse topic exchange" plugin to accomplish uses cases
Take a look here: https://github.com/videlalvaro/rabbitmq-rtopic-exchange
Feedback is most welcome.
On Wed, Oct 30, 2013 at 5:28 PM, Chris <stuff at moesel.net> wrote:
> I've had cases where allowing the publisher to specify wildcards would
> help too. I think it's a very useful custom exchange and would gladly use
> it if RabbitMQ or anyone else ever published it as an extension.
> On Wed, Oct 30, 2013 at 11:29 AM, Lawrence Freil <lef at apago.com> wrote:
>> 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
>> 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.
>> Lawrence Freil
>> lef at apago.com
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss