Configure default_queue_type rabbitmq 3.13.4 but not working

[chungtd203338]

I configured default_queue_type to configure the default queue type on all vhosts in the rabbitmq node as quorum, however when creating a new vhost, it is still in not set status.

I checked the configuration in rabbitmq nodes with the command rabbitmq environment or cat /etc/rabbitmq/rabbitmq.conf both are there but it doesn't seem to work.

[michaelklishin]

We do not have enough information to suggest anything. We do not guess in this community, so please put together an executable way to reproduce.

default_queue_type in rabbitmq.conf has the lowest priority, lower than the same setting for virtual hosts and lower than the client-provided value. Other than this, I cannot suggest anything with a single screenshot for "proof."

[chungtd203338]

I am implementing rabbitmq in cluster model on K8s environment, I want my queues to be scalable and fault tolerant by using quorum queue. I want users to not need to care what type of queue is being used and just need to declare the queue usage, it will default to quorum queue.

I see that from rabbitmq version 3.13.4 there is support to configure default_queue_type for all vhosts in the cluster but when configuring it it doesn't work properly.

Here is rabbitmq.conf file

I made a vhost declaration without specifying default_queue_type

This is my problem, i still don't know how to handle it :(

[michaelklishin]

Apparently for virtual hosts that do not have any metadata at all (no limits, no DQT), the value has no effect. I suspect that every test environment does have virtual host limits because it was contributed by a public cloud infrastructure provider.

I will take a look at how quickly this can be added. For now (and arguably in general), use the per-virtual host DQT.

[michaelklishin]

#12109 should address this. It will ship in 4.0.0. There won't be any more open source 3.13.x releases, so this change won't be backported.

Configuring a DQT and any other virtual metadata key, such as a description or a very high limit, can be used as a workaround with 3.13.7. As well as configuring DQT for individual virtual hosts.

[jonenst]

I got bit by this on 3.13.7 for a toy deployment on my computer, global DQT from rabbitmq.conf was ignored. worked on 4.0.2.

[yuvalgl]

Hi,

any update on this feature for 3.13.x?

it would really help if we could finish a full migration to quorum queues before V4.

[michaelklishin]

@yuvalgl there won't be any more open source RabbitMQ 3.13.x releases. This issue does not affect 4.0.x releases. DQT at the virtual host level is far from being the only or the primary way of moving to quorum queues.

Configuring a DQT and any other metadata key per virtual host, such as a description or a very high limit applications will never surpass, can be used as a workaround with 3.13.7.