<font face="trebuchet ms,sans-serif">Thanks Matthew, that's something I have figured out in the meanwhile, and it's unfortunate that there is not built-in support for something like this.<br></font><br><div class="gmail_quote">
On Fri, May 13, 2011 at 13:30, Matthew Sackman <span dir="ltr"><<a href="mailto:matthew@rabbitmq.com">matthew@rabbitmq.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, Apr 28, 2011 at 05:19:26AM -0700, Simone wrote:<br>
> I need to have two instances of the server located in two different and<br>
> distant places connected by a network link with limited bandwidth. Clients<br>
> need to be able to connect to their nearest instance only and to communicate<br>
> with clients connected to the other server instance using the least<br>
> bandwidth possible. Is this accomplished using clustering, shovel or do they<br>
> have a different purpose? In any case, how would I set-up the infrastructure<br>
> described above?<br>
<br>
</div>Clustering is unlikely to work well over a WAN because Erlang's<br>
clustering (specifically mnesia) doesn't cope well with recovery from<br>
partitions.<br>
<br>
Shovel is an alternative but can only do static configuration. If you<br>
have, or can arrange at the boundaries between your two systems, a fixed<br>
number of queues then the shovel can work well. However, note that with<br>
clustering, you have one logical broker. With shovel, you do not: you<br>
have two distinct brokers.<br>
<font color="#888888"><br>
Matthew<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</div></div></blockquote></div><br>