<br><br><div class="gmail_quote">On 31 October 2011 13:54, Simon MacMullen <span dir="ltr"><<a href="mailto:simon@rabbitmq.com">simon@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 31/10/11 13:53, Pete Kelly wrote:<br>
> Thanks, it mentions federation is incompatible with clusters at release<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2.5 (I assume), is this still the case?<br>
</blockquote>
<br></div>
It's fixed in 2.6.0.</blockquote><div><br></div><div>Cool, so a simple scenario could be:</div><div><br></div><div>Cluster A (USA) <------> Cluster B (Europe)</div><div><br></div><div>which would allow systems in the USA to publish to Cluster A, and systems in Europe to publish to Cluster B.</div>
<div><br></div><div>Cluster A then federates its messages to Cluster B, which is where all the subscribers/consumers live.</div><div><br></div><div>So essentially it's a reliable way to allow the USA to publish messages to RabbitMQ whilst still allowing Europe to subscribe to and consume the messages.</div>
<div><br></div><div>Can it work bi-directionally too? So Europe could federate to the USA too (for the same exchange)? That way we could potentially do it without the cluster at each end.</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
<br>
Cheers, Simon<br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, VMware<br>
</div></div></blockquote></div><br>