[rabbitmq-discuss] A question on federation status reporting

Simon MacMullen simon at rabbitmq.com
Tue Jan 14 10:00:01 GMT 2014


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>
>
>
>



More information about the rabbitmq-discuss mailing list