[rabbitmq-discuss] Archetecture for multi-datacenters

[Simone Busoli]

Hi Wes, shovel will indeed enter an endless loop if you set it up
symmetrically between two brokers. Federation instead has been designed
with an option maxHops which prevents messages from looping. You should
check it out.
On Jan 26, 2012 1:23 AM, "Wes Smith" <Wes_Smith at echopass.com> wrote:

> Situation:****
>
> Each RabbitMQ cluster has multiple nodes (2). My platform I’m working with
> has 2 datacenters each with a RabbitMQ cluster. I need to configure
> RabbitMQ such that any message published to any exchange on any node can be
> consumed by a queue on either cluster.****
>
> ** **
>
> From the web and also a support ticket/question with VMWare I am to
> understand that clustering across the WAN should not be done. I’ve been
> pointed at the shovel plugin to handle communications from one data center
> to the other. I’ve been experimenting with shovel a little to figure out
> how to do this, but I seem to have a loop going on where a published
> message from datacenter A goes to datacenter B, but then B goes ahead and
> shovels it right back to A (more than 800 times per second).****
>
> ** **
>
> I’ve seen a video from 2009 (Tony Garnock-Jones) that discusses this and
> indicated that shovel was being modified to only handle this scenario to
> look at some labels to determine if the message has been to the current
> node, and just drop it if it has.  This change does not appear to have
> happened, unless I’m missing something.****
>
> ** **
>
> Does anyone have a similar scenario or know how to handle high
> availability peer-to-peer connections across a WAN with RabbitMQ?****
>
> ** **
>
> -Wes****
>
> _______________________________________________
> 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/20120126/023797fe/attachment.htm>