[rabbitmq-discuss] A question on federation status reporting

Mon Jan 13 23:49:21 GMT 2014

Thanks Simon!

I'm not sure how I manage to misconfigure my federation to include the
internal queues.

If it helps, here's what my Policies page shows for the federation:

skytap-federation<http://tuk5r1mqvip1.mgt.integ.skytap.com:15672/#/policies/%2F/skytap-federation>
skytapallfederation-upstream-set:allha-mode:all0

And her are the snippets of python code I use to set up federation:

rabbitmq_invoke_http_api(broker_host,
                                      'PUT',

'/api/parameters/federation-upstream/%%2f/upstream-%s' %
(quote_plus(federated_broker)),

'{"value":{"uri":"amqp://%(username)s:%(password)s@%(host)s:%(port)s"}}' %
(federated_settings))

then,

rabbitmq_invoke_http_api(broker_host,
                                      'PUT',
                                      '/api/policies/%2f/skytap-federation',
                                      '{"pattern":"skytap",
"definition":{"federation-upstream-set":"all","ha-mode":"all"}}')

Thanks again,

Matt

On Mon, Jan 13, 2014 at 10:21 AM, Simon MacMullen <simon at rabbitmq.com>wrote:

> Hi Matt.
>
> Federated exchanges declare queues for internal use. These are the queues
> with names beginning "federation: " which you have probably already seen.
>
> It looks like in your case those internal queues are themselves becoming
> federated. This is unlikely to be a useful thing.
>
> You should review your federation policies and make sure those queues are
> not included in them. If you don't intend to federate queues at all then
> the easiest way is to set the federation policy to only apply to exchanges.
>
> I'll also file a bug to prevent those queues from ever federating,
> regardless of policy...
>
> Cheers, Simon
>
>
> On 13/01/2014 18:08, Matt Pietrek wrote:
>
>> We have a bi-directional federation setup between three nodes like this
>> on RabbitMQ 3.2.2:
>>
>> mq_integ/sea <===> mq_integ <===> mq_integ/tuk
>>
>>
>> All three nodes use a "skytap" exchange and the mq_integ/sea
>> and mq_integ/tuk are *_not_* federated with each other
>>
>> Here's what's interesting. In the *mq_integ/sea* broker, the "Federation
>>
>> Upstreams" page is what I'd expect it to be, that is, a connection to
>> mq_integ:
>> Name    URI     Expiry  Message TTL     Max Hops        Prefetch Count
>>  Reconnect Delay
>> Ack mode        Trust User-ID
>> upstream-integ
>> <http://tuk5r1mq1.mgt.integ.skytap.com:15672/#/federation-
>> upstreams/%2F/upstream-integ>
>>
>> amqp://foo:bar@sea_m2:5672
>>  ?       ?
>>
>>
>> However, in the "Federation Status" page for *mq_integ/sea* looks
>>
>> strange (see below). In particular, I see four entries, whereas in
>> RabbitMQ 3.0.2 I only saw one line.
>>
>> In addition, the third entry references the mq_integ/tuk broker, even
>> though I haven't configured mq_integ/sea to know anything about
>> mq_integ/tuk:
>>
>>
>> Connection      URI     Exchange / Queue        Node    State   Inbound
>> message rate    Last
>> changed
>> upstream-integ  amqp://sea_m2:5672      federation: skytap ->
>> mq_integ_queue
>>
>> rabbit at sea_r2
>> running
>>                 2014-01-11 1:35:28
>> upstream-integ  amqp://sea5_m2:5672     federation: skytap ->
>> mq_integ/sea_queue      rabbit at sea_r2
>> running
>>                 2014-01-11 1:35:28
>> upstream-integ  amqp://sea_m2:5672      federation: skytap ->
>> mq_integ/tuk_queue      rabbit at sea_r2
>> running
>>                 2014-01-11 1:35:29
>> upstream-integ  amqp://sea_m2:5672      skytap_exchange
>> rabbit at sea_r2
>> running
>>         0.00/s  2014-01-11 1:35:29
>>
>>
>> Is this what you'd expect to see? Am I not understanding something?
>>
>> Thanks,
>>
>> Matt
>>
>>
>> _______________________________________________
>> 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/20140113/019fbdff/attachment.html>