[rabbitmq-discuss] Federation Topologies & Limitations

Laing, Michael michael.laing at nytimes.com
Sat Jan 18 20:47:59 GMT 2014


I would vote for deduplication where the ring buffer size is set by
configuration.

Effectively that is what we do in a little app that runs on each retail
instance.

Michael


On Thu, Jan 16, 2014 at 6:09 AM, Simon MacMullen <simon at rabbitmq.com> wrote:

> On 15/01/14 19:19, Josh West wrote:
>
>> I am experimenting with different architectures and it seems that in
>> order to prevent message duplications, I'll have to go with a complete
>> graph and max-hops set to 1 -- or in other words, each broker will have
>> to directly federate with the other 100-200 brokers.
>>
>
> Yeah, there isn't any cycle detection in federated exchanges (yet). I keep
> wondering about adding it, but the trouble is that I suspect people really
> want deduplication rather than cycle detection. So that means either
> deduplication buffers that can get arbitrarily large (when do you drop
> message IDs from them) or some sort of routing algorithm to automatically
> remove duplicate routes from the federated broker set (which requires a
> global view at least, and is also probably quite complicated and error
> prone).
>
> So I don't know of any good solutions for large federations other than
> max-hops = 1.
>
> Cheers, Simon
>
> --
> Simon MacMullen
> RabbitMQ, Pivotal
>
> _______________________________________________
> 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/20140118/f16dee36/attachment.html>


More information about the rabbitmq-discuss mailing list