<div dir="ltr">We implement our <span class="">nyt</span>⨍aбrik system as a collection of vhost nodes. The vhosts are named according to a set of rules: role, region, product, organization, environment (dev, stage, production), etc.<div>
<br></div><div>The vhosts are multiply connected via shovels and federation.</div><div><br></div><div>The mapping of vhosts to hosts varies. For example, in production we usually run 1 vhost per host spread across many regions/zones in the cloud. For dev, I can run the exact same configuration on my mac using a single cluster with vhosts representing all the roles, regions, etc.</div>
<div><br></div><div>The point with regard to the OP is that you can architect using multiple vhosts, and there can be benefits, as we realize. But you should consider the separation Simon referred to as a virtue, using it to maintain a flexible and reliable arrangement of loosely coupled strong components.</div>
<div><br></div><div>Best regards,</div><div><br></div><div>Michael</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 24, 2014 at 6:53 AM, Simon MacMullen <span dir="ltr"><<a href="mailto:simon@rabbitmq.com" target="_blank">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="HOEnZb"><div class="h5">On 22/03/2014 11:33PM, Adam Smith wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
   I want to write a custom exchange type plugin to accomplish the<br>
following:<br>
<br>
1. My application publishes messages to a custom exchange CUST in vhost<br>
MYAPP<br>
2. The custom exchange plugin in turn publishes the same message to<br>
         a. exchange X in vhost CL1<br>
         b. exchange X in vhost CL2<br>
         .....<br>
The number of CLx vhosts can vary at different points in the<br>
application's lifetime. Any pointers on how/whether it can done would be<br>
greatly appreciated.<br>
</blockquote>
<br></div></div>
It can be done, since rabbit_exchange_type:route/2 returns a list of #resource{}s for the queue names to route to - and each #resource{} contains a virtual host. So you could mess with virtual hosts according to whatever logic you want in that function.<br>

<br>
However (and it's quite a big however), RabbitMQ (and AMQP) are definitely not designed to work like that. Each virtual host is supposed to be a self-contained universe, so by routing across virtual hosts you are breaking the rules.<br>

<br>
Some issues you will experience (I won't guarantee that this is a complete list):<br>
<br>
1) You won't be allowed to establish a cross-vhost binding, so you'll have to determine how cross-vhost routing works in practice without reference to bindings.<br>
<br>
2) The permissions system won't take any account of any cross-vhost routing you do.<br>
<br>
3) Message rates in the management plugin might be garbled.<br>
<br>
4) Future changes to the broker might break this completely (for example, if we ever move to per-vhost message stores). No such changes are currently on our radar though.<br>
<br>
So this is very much "at your own risk". Virtual hosts are *designed* to keep things completely separate, so if you want to route messages between them then maybe your design should be rethought.<br>
<br>
Cheers, Simon<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, Pivotal<br>
______________________________<u></u>_________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.<u></u>rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/<u></u>cgi-bin/mailman/listinfo/<u></u>rabbitmq-discuss</a><br>
</font></span></blockquote></div><br></div>