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

[Alvaro Videla]

Hi,

I've created a "reverse topic exchange" plugin to accomplish uses cases
like yours.

Take a look here: https://github.com/videlalvaro/rabbitmq-rtopic-exchange

Feedback is most welcome.

Regards,

Alvaro


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.
>
> -Chris
>
>
> On Wed, Oct 30, 2013 at 11:29 AM, Lawrence Freil <lef at apago.com> wrote:
>
>> 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
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20131102/a09d0688/attachment.htm>