Last checked and updated on 01 May 2026What Is New in RabbitMQ 4.1
RabbitMQ 4.1.0 introduces significant performance enhancements, new protocol features, and quality-of-life improvements for operators. The focus is on quorum queue scalability, AMQP 1.0 functionality, and simplifying cluster management.
| Category | Key Changes |
|---|---|
| Performance | Quorum queue log reads offloaded to channels for better throughput and CPU utilization. |
| New Features | Initial AMQP 1.0 filter expressions; rabbitmqadmin v2 CLI tool; AMQP 1.0 dynamic queues and multi-routing keys. |
| Improvements | Automatic enabling of some feature flags; better peer discovery resilience; more stream and Prometheus metrics. |
| Breaking Changes | Increased pre-auth AMQP frame size (breaks old Node.js amqplib); reduced default MQTT packet size; deprecated etcd SSL options. |
| Bug Fixes | Quorum queue leader election lag; classic queue priority exceptions; mixed-version cluster dead-lettering issues. |
How does RabbitMQ 4.1 improve quorum queue performance?
The core improvement is the offloading of quorum queue log read operations from the queue process to AMQP channels (or sessions/connections). This architectural change has several practical benefits.
Previously, a single queue process could become a bottleneck when handling both publishing and consuming traffic. Now, consumer operations can be parallelized across channels. This leads to higher consumer throughput, especially when you have multiple concurrent consumers on the same queue.
It also reduces interference. Heavy publishing activity has less impact on the rate at which messages are delivered to consumers. Finally, it improves CPU core utilization per queue, assuming your node has multiple cores available. This change makes quorum queues more scalable for high-demand workloads.
What new filtering capabilities does AMQP 1.0 get?
RabbitMQ 4.1 adds initial support for AMQP 1.0 Filter Expressions, specifically the properties and application-properties filters based on a working draft of the spec. This is a game-changer for stream consumption patterns.
Clients can now attach to a stream with a filter expression, like application-properties.color = 'red'. RabbitMQ will then only deliver messages matching that filter to that consumer. This enables a powerful pattern: multiple concurrent clients can each consume a different subset of messages from the same stream while preserving the global message order.
This reduces unnecessary network traffic and client-side processing, as clients only get the data they're interested in. The feature also supports string prefix and suffix matching, adding flexibility for topic-like filtering within a ordered stream.
What are the critical breaking changes?
Three changes require immediate attention before upgrading: a client library requirement, an MQTT default, and a deprecated command.
AMQP 0-9-1 Frame Size Increase
The pre-authentication maximum frame size has been raised from 4096 to 8192 bytes to better support large OAuth 2.0 JWT tokens. Clients that hardcode a frame_max below 8192 will fail to connect. The Node.js library amqplib versions before 0.10.7 used a default of 4096 and must be upgraded.
MQTT Maximum Packet Size
The default maximum packet size for MQTT connections has been reduced from 256 MiB to 16 MiB, aligning with the default max_message_size. You can override this with mqtt.max_packet_size_authenticated, but it cannot exceed max_message_size.
Deprecated Command
The rabbitmqctl force_reset command is now deprecated as it is incompatible with the upcoming Khepri metadata store. Use rabbitmqctl reset instead.
How are feature flags easier to manage now?
The feature flag system, which became mandatory in earlier releases, gets several usability improvements. The most notable is that certain required feature flags will now be enabled automatically on node boot if all nodes in the cluster support them.
This removes a manual step from the upgrade process for those flags. However, this doesn't apply to all feature flags—some still require explicit enabling. The goal is to reduce the operational overhead and potential for error when rolling out new cluster-wide features.
What's new in monitoring and tooling?
New diagnostics and metrics provide deeper visibility into cluster health and message flow.
- New Health Check:
rabbitmq-diagnostics check_for_quorum_queues_without_an_elected_leaderhelps identify quorum queues stuck without a leader. - Prometheus Metrics: A new histogram for published message sizes, broken down by protocol (AMQP 0-9-1, AMQP 1.0, MQTT). This helps you understand your message size distribution.
- rabbitmqadmin v2: A complete rewrite of the HTTP API CLI tool. It's now a standalone native binary with a TOML config file, supports more operations (federation, shovels, health checks), and has better interactive mode support.
FAQ
I'm using the Node.js amqplib client. What do I need to do before upgrading?
You must upgrade amqplib to version 0.10.7 or later. Older versions use a default maximum frame size of 4096 bytes, which is now below the server's minimum pre-auth frame size of 8192 bytes, causing connection failures.
Does the new quorum queue performance improvement require configuration?
No. The offloading of log reads to channels is a core server change and is enabled automatically. You should see improved throughput and CPU utilization under load without any action.
Can I use AMQP 1.0 filter expressions with classic or quorum queues?
No. The filter expression feature is specifically for consuming from streams via AMQP 1.0 connections. It does not apply to other queue types.
Why was the default MQTT packet size reduced, and how do I revert it?
It was reduced to 16 MiB to match the default maximum message size, preventing confusion. If you need a larger size, you can set mqtt.max_packet_size_authenticated in your configuration, but ensure it does not exceed your configured max_message_size.
What happens if I run a mixed-version cluster with 4.1 and 4.0 nodes?
RabbitMQ 4.1.0 nodes are compatible with 4.0.x nodes in a cluster. However, new 4.1-specific features (like certain feature flag auto-enablement) won't be available until all nodes are upgraded. Mixed-version clusters are for rolling upgrades only and should not be run for extended periods.