Compose for RabbitMQ version 3.8 has been released, but with it comes the end of version 3.7, which set to retire on March 31, 2020.

In line with our release policy, version 3.8 will be marked as preferred this week. 30 days from now, we'll remove RabbitMQ 3.7 on Compose, but if you've already provisioned it, you can continue to use it. However, you won't be able to restore a backup into a deployment on version 3.7.

By September 14, 2020, all Compose for RabbitMQ users are expected to be on RabbitMQ version 3.8.

RabbitMQ 3.8 is a major version that has introduced a number of changes. One of the more significant changes to the messaging queue is the introduction of quorum queues. Let's talk a little about those below.

What are Quorum Queues

Using quorum queues can significantly improve high-availability of a deployment depending on its use case. The main feature of quorum queues is a FIFO queue which makes use of Raft to provide high-availability via replication in a cluster. In a quorum, the available majority of nodes decides which of the existing followers gets elected as leader. 

The existing queues of type classic have to rely on the mirrored queues concept to achieve high-availability, which has to be applied and managed over the whole cluster life cycle.

Quorum Queue Use Cases

Quorum queues can be considered for use cases that depend on long running queues that require data integrity and high-availability rather than flexibility and short-lived life cycles. Not all features are available for quorum queues, so it is recommended to verify the feature matrix when considering quorum queues.

The following points have to be considered when using quorum queues:

• Clients - Have to make use of manual acknowledgements and publisher confirms

• Resources - A quorum queue requires a service instance with a generous amount of memory and disk to keep its promise. Check out RabbitMQ's recommendation to determine your resource needs for running quorum queues.

• Configuration

  • delivery-limit – Handles messages that cause a consumer to continuously redelivered messages without consuming them completely
  • max-length-bytes – As every queue the queue length must not grow unconditionally, and needs to be well maintained and monitored.

Scaling and Quorum Queues

If you decided to use quorum queues in your Compose for RabbitMQ deployment, note that your deployment will scale up to a minimum of six units. Due to the nature of quorum queues and its taste for resources, your deployment will automatically scale up to the minimum recommended units so that your deployment runs smoothly within the Compose ecosystem.

Upgrading Compose for RabbitMQ

For existing RabbitMQ 3.7 users, upgrading your deployment is a breeze. Just make sure that you run tests make sure that there aren't any breaking changes to your application between versions 3.7 and 3.8.

This is an in-place upgrade from version 3.7 to version 3.8. Before upgrading, we recommend scaling up your deployment from the Resources panel, so that you have enough memory available for queue synchronization.

When you've done that, head over to the Settings panel by clicking on the Settings button in the Compose UI.

Next, read the information in the Change Version panel. Note that this is a rolling-upgrade, which means that if you have queues full of messages, it might be a little slower to upgrade. Also, if you have unmirrored non-persistent messages, the upgrade will fail. When you're ready to upgrade, click on the Change Version button and the process will begin.

After a few minutes, your deployment will be on version 3.8 and ready to go.

That's all ...

If you have any questions about upgrading your Compose for RabbitMQ deployment, reach out to us at support@compose.com.