[rabbitmq-discuss] A question on federation status reporting

Fri Jan 17 01:11:34 GMT 2014

Simon,

Ultimately, I got this to work by adding:

"apply-to":"exchanges"

to my profile definitions.

However, one issue you may want to know about. After reapplying my profile,
I didn't see a reduction in links like I'd expect, despite the fact that
the

 In fact, even restarting the broker caused the broken state to remain.

In order to get this policy to take effect, I need to restart the brokers.
Not sure if this is expected behavior or not.

Thanks,

Matt

On Tue, Jan 14, 2014 at 2:00 AM, Simon MacMullen <simon at rabbitmq.com> wrote:

> Hi Matt.
>
> Your policy applies to exchanges and queues with "skytap" in the name -
> that includes the internal queues. Since the policy includes "ha-mode" I'm
> assuming you want it to apply to both exchanges and queues - so you could
> (1) change the regex to "^skytap" (i.e. names have to start with skytap,
> not just contain it or (2) create a second policy to apply "ha-mode" to
> queues and set the current policy to apply to exchanges only.
>
> Note that as of 3.2.x policies can be set to apply to exchanges or queues
> or both: http://www.rabbitmq.com/parameters.html#policies
>
> Cheers, Simon
>
>
> On 13/01/2014 23:49, Matt Pietrek wrote:
>
>> 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>
>>
>> skytap  all
>> federation-upstream-set:        all
>> ha-mode:        all
>>
>>         0
>>
>>
>>
>> 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
>> <mailto: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
>>
>>         <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
>>         <mailto:rabbitmq-discuss at lists.rabbitmq.com>
>>         https://lists.rabbitmq.com/__cgi-bin/mailman/listinfo/__
>> rabbitmq-discuss
>>         <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/20140116/67ecdca4/attachment.html>