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

[Chris]

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<rabbitmq-discuss at lists.rabbitmq.com>
> https://lists.rabbitmq.com/**cgi-bin/mailman/listinfo/**rabbitmq-discuss<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/20131030/a3b75fe8/attachment.htm>