Migration to quorum queues

[Iveliana Bozhilova]

Hello,

We are migrating to quorum queues because when the node that the rabbitmq broker is on dies, the consumers are not able to recover with another node in the cluster and exceptions are thrown. 

After a lot of testing with quorum queues it seems that when ALL of the consumer queues are quorum, the recovery is successful when the node dies and the consumers continue working using the rabbitmq broker on another node. But when we change only some of the queues to quorum and leave some of the queues as classic ones, the same problem - after the node that the rabbitmq broker is on dies, the consumers are not able to recover with another node in the cluster. 

Could you explain to me what is the difference between changing some queues to quorum versus all of the queues to quorum (with the exception of cloud bus anonymous queues, of course)?

[Michal Kuratczyk]

Hi,

You didn't explain what you mean by "not able to recover" so it's hard to tell what's going on. If your clients struggle to recover with classic queues (which is a potential problem in its own right),

then it doesn't seem surprising that they also struggle with that even when some of the queues are now quorum queues.

Please explain what you mean by unable to recover and how you use classic queues - are they durable, mirrored, etc? Any particular reason to keep classic queues if you can migrate them all?

Note: classic queues still have valid use cases but your description suggests that you ultimately want to move all to quorum queues.

Best,

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/CALaz6hCeraOQ61vLXxtwiDwXxf%3DGdukww5L_PzQMzsAzyiDkKg%40mail.gmail.com.

--

Michał

RabbitMQ team

[Iveliana Bozhilova]

Hi,

What I meant with "not able to recover" is that the consumer cannot continue its work - the spring cloud bus anonymous queue fails its declaration and starts throwing 

"Consumer threw missing queues exception, fatal=false org.springframework.amqp.rabbit.listener.QueuesNotAvailableException: Cannot prepare queue for listener. Either the queue doesn't exist or the broker will not allow us to use it.". So the problem is that this anonymous queue cannot be created for some reason.

All of the classic queues are durable and not mirrored. We will probably migrate all queues to quorum, just would like an explanation why this is happening. What is the difference to this spring cloud bus anonymous queue being created when using some quorum queues vs all quorum queues?

You received this message because you are subscribed to a topic in the Google Groups "rabbitmq-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rabbitmq-users/G7IOnFLdciQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rabbitmq-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/CAA81d0uP_rO1qXmKZiMDbUJPsPiWjWrpyK%3D-6%3DUBx2tpWCuqpw%40mail.gmail.com.

[kjnilsson]

Might be worth inspecting the broker logs to see more details on why the declaration was not allowed. Most likely you are using an argument combination that isn't allowed for quorum queues but when using an abstracted framework like Spring that kind of thing can be hard to determine if they just return a generic error message like that.

[Gary Russell]

What version of spring-cloud-stream are you using? All supported versions set the x-queue-master-locator​ argument to client-local​, to ensure that the auto-delete, exclusive queues are located on the node we are connected to. This was fixed several years ago.

Older versions didn't do that, and you could get the behavior you are seeing.

You can also set the master-locator​ using a policy.

---

From: rabbitm...@googlegroups.com <rabbitm...@googlegroups.com> on behalf of kjnilsson <kjni...@gmail.com>
Sent: Monday, January 16, 2023 12:47 PM
To: rabbitmq-users <rabbitm...@googlegroups.com>
Subject: Re: [rabbitmq-users] Migration to quorum queues

 

!! External Email

To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/5a9b8ed4-85ef-4b6e-a459-8fc3d2190071n%40googlegroups.com.

!! External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.

[Iveliana Bozhilova]

@kjnilsson - I don't think this is the problem because if I try for example to create a queue with invalid/not allowed arguments it clearly states that that is the problem when I run the application (at the beginning I tried to make the anonymous queues as quorum and I got an invalid arguments error).

@Gary Russell - We are using spring-cloud-starter-bus-amqp 3.1.0 version which uses spring-cloud-starter-stream-rabbit 3.2.1 version.

The x-queue-master-locator is set as client-local when the anonymous queues are created (when the application is started). So I don't see how this could be the issue.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/BL0PR05MB4708FFE9772E2967B533F20EAAC69%40BL0PR05MB4708.namprd05.prod.outlook.com.