[rabbitmq-discuss] Writing custom exchange type plugin

[Laing, Michael]

We implement our nyt⨍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.

The vhosts are multiply connected via shovels and federation.

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.

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.

Best regards,

Michael


On Mon, Mar 24, 2014 at 6:53 AM, Simon MacMullen <simon at rabbitmq.com> wrote:

> On 22/03/2014 11:33PM, Adam Smith wrote:
>
>> Hi,
>>    I want to write a custom exchange type plugin to accomplish the
>> following:
>>
>> 1. My application publishes messages to a custom exchange CUST in vhost
>> MYAPP
>> 2. The custom exchange plugin in turn publishes the same message to
>>          a. exchange X in vhost CL1
>>          b. exchange X in vhost CL2
>>          .....
>> The number of CLx vhosts can vary at different points in the
>> application's lifetime. Any pointers on how/whether it can done would be
>> greatly appreciated.
>>
>
> 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.
>
> 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.
>
> Some issues you will experience (I won't guarantee that this is a complete
> list):
>
> 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.
>
> 2) The permissions system won't take any account of any cross-vhost
> routing you do.
>
> 3) Message rates in the management plugin might be garbled.
>
> 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.
>
> 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.
>
> Cheers, Simon
>
> --
> Simon MacMullen
> RabbitMQ, Pivotal
> _______________________________________________
> 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/20140325/82c230d3/attachment.html>