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

What Is New in RabbitMQ 3.5

RabbitMQ 3.5 introduced significant enhancements focused on protocol support, management, and core stability. The key updates are summarized below.

How Did MQTT Support Evolve in 3.5?

Version 3.5 marked a major step by including a supported MQTT plugin out of the box. Before this, MQTT support was experimental or required manual compilation.

This plugin enabled RabbitMQ to act as a full MQTT 3.1 broker, bridging the gap between IoT-style messaging and AMQP-based enterprise backends. In practice, it allowed devices publishing MQTT messages to have those messages consumed by AMQP or STOMP clients seamlessly.

Key MQTT Plugin Details

• Plugin name: rabbitmq_mqtt
• Supported MQTT QoS levels 0 and 1.
• Topic routing mapped directly to AMQP exchanges and routing keys.

What Management and Monitoring Upgrades Were Added?

The management plugin received several new endpoints and data exposures in its HTTP API.

You could now retrieve more granular statistics on per-channel and per-connection basis, which was crucial for debugging high-throughput systems. The API also improved its JSON structure for consistency.

# Example: Listing connections with new details
GET /api/connections
# Response included more metrics on message rates and state.

For operators, the Windows service management scripts were overhauled, making start/stop operations more reliable.

Were There Core Performance and Memory Tweaks?

Yes, the 3.5 series included optimizations for memory use under certain workloads, particularly for persistent messages and when using lazy queues.

The internal message store saw improvements that reduced disk I/O overhead. This mattered because earlier versions could see performance degradation with many idle queues holding persistent messages.

Garbage collection settings for the underlying Erlang VM were also tuned for better long-term stability, reducing the risk of memory spikes.

What Changed for Shovel and Federation?

The Shovel plugin, used for reliable message transfer between brokers, became more configurable and resilient.

You could now define Shovel links dynamically via the management API or statically via config file. The plugin better handled reconnection logic and network partitions, making it more suitable for WAN links.

# Static shovel configuration in rabbitmq.config
{rabbitmq_shovel, [
  {shovels, [
    {my_shovel, [
      {sources, [...]},
      {destinations, [...]}
    ]}
  ]}
]}

Were Any Features Deprecated or Removed?

The primary deprecation was the legacy Erlang client driver, which was part of the server distribution. Its functionality was superseded by the standalone amqp_client library.

This change streamlined the server package and pushed users towards the maintained, versioned client libraries. It didn't affect Java, .NET, or other language clients.