RabbitMqServer cannot start on RabbitMQ 4.4: .outq queues are declared transient and non-exclusive

ServiceStack Rabbit MQ
1

RabbitMqServer fails to start against RabbitMQ 4.4.0 with its default configuration. RabbitMQ now refuses queues that are neither durable nor exclusive, and ServiceStack declares one such queue mq:<Message>.outq, for every registered message type.

What we see

RabbitMQ 4.4.0 on Erlang/OTP 28, default configuration. Our services register handlers with RegisterHandler<T> and call Start().

RabbitMQ’s log:

Feature `transient_nonexcl_queues` is deprecated. By default, this feature is not permitted anymore.
operation queue.declare caused a connection exception internal_error

The client:

RabbitMQ.Client.Exceptions.OperationInterruptedException: ... code=541, text='INTERNAL_ERROR - Feature transient_nonexcl_queues is deprecated.

We get the same result with ServiceStack.RabbitMq 10.4.2 on .NET 10 and with 6.0.2 on .NET Framework 4.8.1. Both work on RabbitMQ 3.13.

Where it comes from

RegisterTopic in ServiceStack.RabbitMq/RabbitMqExtensions.cs on main:

channel.QueueDeclare(queueName, durable: false, exclusive: false, autoDelete: false, arguments: args);

RegisterQueues always calls it for QueueNames<T>.Out. As far as I can see, there is no way to change this from outside:

  • CreateTopicFilter receives only the arguments dictionary, not the durable or exclusive flags.
  • DisablePublishingToOutq = true stops messages being published to .outq, but the queue is still declared. We already set this, because nothing in our application reads .outq.

Workaround

Adding this to rabbitmq.conf lets everything run on 4.4.0:

deprecated_features.permit.transient_nonexcl_queues = true

RabbitMQ’s log says the feature will be removed in a future major version, so this only buys time. RabbitMQ 3.13 is out of community support, which is why we are moving to 4.x.

What would help

Either of these would let ServiceStack run on RabbitMQ 4.4 as installed:

  1. Do not declare .outq when DisablePublishingToOutq is true, or add a setting that skips topic queues.
  2. A setting, or a filter that can set the flags, so .outq can be declared durable.

One question for existing installations: brokers that already hold transient mq:*.outq queues cannot have them redeclared as durable, since RabbitMQ rejects a redeclaration with different properties. Would you expect applications to delete those queues on upgrade, or would ServiceStack handle it?

Is there a supported way to do this today that I’m missing? If not, could it be considered for an upcoming release? I am happy to test a pre-release build against 4.4.

2

Thanks for reporting, it looks like DisablePublishingToOutq stopped publishing but didn’t prevent .outq declarations, and CreateTopicFilter could not change the durability flags.

I’ve implemented a fix where:

  • Output queues are now durable and non-exclusive by default.
  • A new DisableTopicQueues option skips output queue declarations during startup.
  • A new DurableTopicQueues setting controls output queue durability on both RabbitMqServer and standalone RabbitMqMessageFactory instances.

Since your application doesn’t use .outq, you can configure:

var mqServer = new RabbitMqServer(connectionString) {
    DisablePublishingToOutq = true,
    DisableTopicQueues = true,
};

For existing installations, ServiceStack will not automatically delete queues. Applications adopting durable output queues must take care to delete the affected transient .outq queues before restarting. Applications skipping output queue provisioning don’t need to recreate those queues.

Should it be needed, DurableTopicQueues = false retains the previous declaration flags, alongside the broker override you identified.

I’ve verified startup and message processing against RabbitMQ 4.4.0 with its default configuration and RabbitMQ 3.13.7, using both polling and subscription workers. Durable output queues do not change notification messages to persistent delivery.

This change is available from v10.5.1 which is available in the pre-release packages, can you please test and let me know how it behaves in your environment.

1 Like