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

What Is New in RabbitMQ 2.7

RabbitMQ 2.7 focuses on foundational improvements to core subsystems, paving the way for future scalability and reliability features. The key updates are summarized below.

How did RabbitMQ 2.7 improve core database performance?

The most critical upgrade in 2.7 is under the hood: a major overhaul of the Mnesia database layer. This is the system RabbitMQ uses for storing queue, exchange, and binding metadata.

In practice, this rewrite drastically reduces table contention and improves transaction throughput. For clusters, this means more stable performance during topology changes and under heavy load. You'll see less latency when declaring queues or bindings, especially in busy systems.

What new control capabilities were added for messages?

RabbitMQ 2.7 introduced the delivery_mode property as a per-message control flag. Previously, persistence was primarily a function of queue durability.

Per-Message Persistence Control

Now, a publisher can explicitly decide if a specific message should survive a broker restart, regardless of the queue's settings. This is done by setting the delivery_mode property in the message's Basic Properties.

# Example: Publishing a persistent message
channel.basic_publish(
    exchange='',
    routing_key='my-queue',
    body='Important Data',
    properties=pika.BasicProperties(
        delivery_mode=2,  # Persistent message
        content_type='text/plain'
    )
)

This matters because it gives developers finer-grained control over the trade-off between performance and reliability on a per-message basis.

How can plugins and tools react to broker events?

Version 2.7 added a built-in, internal exchange for system events. This allows plugins and external tools to subscribe to broker lifecycle events.

The `amq.rabbitmq.event` Exchange

This new topic exchange, amq.rabbitmq.event, publishes events about resource creation/deletion (users, vhosts, queues) and node activity. For example, a custom monitoring tool can bind a queue to this exchange and listen for queue.created events.

It enables a more decoupled and reactive ecosystem. Before this, monitoring often required polling the management API or parsing logs.

What changes were made for protocol adapters?

The STOMP adapter received significant attention, making it more robust and feature-complete for simple messaging use cases.

Improvements included better support for message headers, heartbeats, and error handling. This made RabbitMQ a more viable option for environments using STOMP for web messaging, alongside its core AMQP strength.