[rabbitmq-discuss] HA Queue declaration

Austin Buckner abuckner at homeaway.com
Fri Dec 28 16:13:29 GMT 2012

It seems I should read the errors more closely. In each env we have 2
queues per app. 
I deleted the 01s for all except one in which case I deleted the 02 and
thus the name collision on startup.
Thanks for making me read what I type all is well now, I had the right
notion but not a comprehensive execution.

On 12/28/12 8:35 AM, "Tim Watson" <tim at rabbitmq.com> wrote:

>On 28 Dec 2012, at 14:29, Austin Buckner wrote:
>> When I try pushing it out to our test env I get this error from the
>>rabbit logs:
>> connection <0.15043.4>, channel 1 - error:
>> {amqp_error,precondition_failed,
>>             "inequivalent arg 'x-ha-policy'for queue 'queue.name' in
>>vhost '/': received the value 'all' of type 'longstr' but current is
>>             'queue.declare'}
>This error is quite explicit - there is already a queue with the same
>name in that vhost, for which the x-ha-policy is set to 'none' -
>declaring it with a different policy is an error.
>> I've tried pushing it out with the non HA queues still up, and also
>>with deleting them before trying to spin up the new ones and no dice
>>still can't create these queues.
>If you've completely deleted the queues first, and redeclared them for
>the first time with x-ha-policy=all then it should work. If that's not
>the case, please post a transcript so we can reproduce the problem.
>> I don't know if its worth noting that the queue names are still the
>>same all I'm trying to do is simply declare them with the x-ha-policy =
>If they already exist with a different x-ha-policy then that won't work.
>Otherwise, you should be fine!
>> Map<String,Object> params = new HashMap<String, Object>();
>> params.put("x-ha-policy", "all");
>> params.put("x-expires", TimeUnit.HOURS.toMillis(24));
>> Has anyone else run into this problem? I realize I can upgrade to 3.0.1
>>and implement HA queues at the broker level but at this point I want to
>>try and get this to work without having to go through and upgrade all of
>>our envs.
>Whilst we always suggest upgrading where possible, this *should* work on
>2.x series brokers as long as the declaration doesn't clash with an
>existing object (having different parameters).
>rabbitmq-discuss mailing list
>rabbitmq-discuss at lists.rabbitmq.com

More information about the rabbitmq-discuss mailing list