[rabbitmq-discuss] Federation help

Simon MacMullen simon at rabbitmq.com
Mon Nov 28 10:56:40 GMT 2011


On 26/11/11 18:27, James Aimonetti wrote:
> Wanting to add federation to existing brokers but not sure I'm
> understanding the semantics involved.

Hi. Thanks for the reminder that an upgrade to the federation docs is 
overdue :)

> Let's say I have three exchanges, {events, topic}, {control, direct},
> and {config, topic}, all three of which are on both brokers (in
> different datacenters).
>
> My current rabbit.config looks like:
>
> [{rabbitmq_federation
>    ,[{exchanges, [
> 		 [{exchange, "config"}
> 		  ,{type, "topic"}
> 		  ,{upstream_set, "config_exchanges"}
> 		 ]
> 		 ,[{exchange, "control"}
> 		  ,{type, "direct"}
> 		  ,{upstream_set, "control_exchanges"}
> 		 ]
> 		 ,[{exchange, "events"}
> 		  ,{type, "topic"}
> 		  ,{upstream_set, "events_exchanges"}
> 		 ]
>                  ]
>           ,{upstream_sets, [{"control_exchanges", [[{connection,
> "broker2"}]]}
>                            ,{"events_exchanges", [[{connection, "broker2"}]]}
> 		          ,{"config_exchanges", [[{connection, "broker2"}]]}
> 	]}
>      ,{connections, [{"broker2", [{host, "broker2.example.com"}]}]}
>      ,{local_nodename, "broker1.example.com"}
>    ]}
>   ...more config

For the record you don't need to have a different upstream_set for each 
exchange, unless you actually want each exchange to federate with 
different brokers.

> I have an almost identical config on brokers 1 and 2 (with hostnames
> obviously adapted). Both startup fine (*sidenote: I had to set
> ERL_LIBS=/path/to/rabbit/plugins to get the federation plugin to work -
> the VM couldn't find the amqp_connection module, even after enabling the
> amqp_client plugin).

Really? Are you using deb / rpms? Have you moved anything around?

> I see both brokers communicating about the
> exchanges - lines similar to:
>
> =INFO REPORT==== 26-Nov-2011::18:04:01 ===
> Federation exchange 'control' in vhost '/' connected to
> broker2.example.com:/:control
>
> I start my application (in a separate VM) connecting to broker1, try to
> declare my exchanges as part of my app's init, and get errors like:

You don't need to. The exchanges part of the federation config will 
declare those exchanges when the broker starts up.

If you do want to declare them in your app, read the section "Declaring 
Federation Exchanges Over AMQP" in the README.

> ...snip...
> {server_initiated_close,406,
>                        <<"PRECONDITION_FAILED - cannot redeclare exchange
> 'control' in vhost '/' with different type, durable, internal or
> autodelete value">>}},
>                {gen_server,call,
>                    [<0.78.0>,
>                     {call,
>                         {'exchange.declare',1,<<"control">>,<<"direct">>,
>                             false,false,false,false,false,[]},
> ...snip...
>
> So I explicitly set type, durable, internal, and autodelete to 'false'
> in my federation configs, but to no avail.

The problem is likely to be the type - they need to be of type 
"x-federation". You might want to temporarily enable the management 
plugin so you can see what's going on.

> I should note I have no
> durable exchanges or queues in this system; everything is ephemeral.
> Neither broker is clustered with any others.
>
> I do see errors when I restart a broker similar to:
>
> =ERROR REPORT==== 26-Nov-2011::18:04:00 ===
> connection<0.2064.0>, channel 2 - error:
> {amqp_error,not_found,
>              "no exchange 'federation: control ->  broker2.example.com B'
> in vhost '/'",
>              'exchange.delete'}

Yeah, these are harmless - federation uses an intermediate exchange on 
the upstream which gets recreated on connect. It has to try to delete it 
to make *sure* it's not there (although it probably isn't anyway) - but 
there's currently no way to not treat that as an error.

> My understanding (which may be bass-ackwards) is that by setting up the
> 'control' exchange to federate with broker2, broker1 will receive
> payloads from broker2's 'control' exchange and route them to any queues
> bound to broker1's 'control' exchange, and that my application code
> remains relatively unchanged to take advantage of that. The converse
> too: since broker2 is connecting to broker1, any payloads my apps on
> broker1 send to the 'control' exchange will be relayed to broker2.

Yes, although the links are unidirectional so you need to set up 
federation in both directions.

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, VMware


More information about the rabbitmq-discuss mailing list