[rabbitmq-discuss] A question on federation status reporting
Matt Pietrek
mpietrek at skytap.com
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>
More information about the rabbitmq-discuss
mailing list