RabbitMQ 3.4: What's New, Release History & EOL Status

What Is New in RabbitMQ 3.4

RabbitMQ 3.4 introduced significant improvements focused on protocol support, operational tooling, and core stability. This release marked a major step forward for users of MQTT and for operators managing large clusters.

How did MQTT support improve in RabbitMQ 3.4?

The MQTT plugin was promoted from experimental to a fully supported, stable component. This meant it was now bundled with the server, deemed production-ready, and received first-class support. The plugin gained improved handling of QoS 1 and 2 flows, better session management, and more configurable topic permissions.

In practice, this allowed IoT and mobile applications using MQTT to rely on RabbitMQ as a robust, scalable message broker. The integration leveraged RabbitMQ's existing authentication, authorization, and clustering features, making it a compelling alternative to standalone MQTT brokers.

What new management and operational features were added?

RabbitMQ 3.4 added the ability to manage the Shovel plugin via the rabbitmqctl command-line tool. Before this, Shovel configuration was static and file-based. This change allowed operators to dynamically create, update, and delete Shovel links at runtime, greatly improving flexibility in building fault-tolerant federation topologies.

AMQP Consumer Cancellation

A small but critical AMQP 0-9-1 extension was introduced: consumer cancellation notifications. This allowed a server to notify a client if a queue was deleted or a consumer was lost due to other reasons, preventing clients from waiting indefinitely for messages that would never arrive.

channel.basicConsume(queueName, new DefaultConsumer(channel) {
    @Override
    public void handleCancel(String consumerTag) throws IOException {
        // Logic to handle consumer cancellation
    }
});

How were memory usage and clustering made better?

The core server saw optimizations in how it managed memory for messages and connections, reducing the overall footprint under similar loads. This was crucial for deployments with many concurrent connections or long queues.

Cluster formation and node recovery logic was hardened. The fixes addressed edge cases where nodes could get stuck during startup or fail to rejoin a cluster after a network partition, improving overall system resilience.

What happened to the STOMP plugin in this release?

The STOMP plugin received substantial updates for better compliance with the STOMP 1.2 specification. It improved header handling, added support for heart-beating as per the spec, and fixed several connection lifecycle bugs. This made RabbitMQ a more reliable choice for STOMP-based clients, often used in web messaging.