<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Apr 12, 2014 at 8:06 AM, Michael Klishin <span dir="ltr"><<a href="mailto:mklishin@gopivotal.com" target="_blank">mklishin@gopivotal.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="">One straightforward way of “routing” would be to use multiple exchanges<br></div>
that are federated to different “storage” clusters.<br>
<br>
You can name them sla1, sla2 and so on, for example.</blockquote><div><br></div><div>Publishing definitely seems to be the easy part. This is more or less what I had planned to do. The trick of course comes with the consumers.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
> If both consumers and producers connect to different, non-clustered<br>
> "router" systems, how do I configure federation to achieve this?<br>
<br>
</div>Publishers publish to different exchanges in the “router” cluster, federation<br>
propagates messages to N “storage” clusters where consumers declare the queues<br>
they need and bind them to federated [destination] exchanges. Then consume<br>
messages as if they were published to their cluster.<br></blockquote><div><br></div><div>So this would require, for example, the consumers to connect directly to the storage clusters in order to instantiate their queues and then federate those queues to exchanges on the router systems?</div>
</div></div></div>