We are pleased to announce for our service offering, IBM Messages for RabbitMQ, the Preferred status for RabbitMQ 3.8. 

RabbitMQ 3.8 brings with it a bevy of new features, including the most noteworthy—the introduction of quorum queues. This new queue type is a replicated queue based on the Raft consensus algorithm. The quorum queue is RabbitMQ’s strategic queue type for high availability and data safety and is aimed to replace classic mirrored queues. With quorum queues, the RabbitMQ community is looking to overcome synchronization issues of classic mirrored queues. For instance, queue synchronization problems are nonexistent since a quorum queue can only confirm the reception of a message if the majority of replicas have written it to disk.

We highly recommend that you leverage quorum queues in favor of classic mirrored queues when using the IBM Messages for RabbitMQ service. 

Changes to service

As part of delivering the best RabbitMQ experience possible, we are making some changes to our service to improve resiliency and flexibility:  

  • For a message delivery with guaranteed durability and consistent quality of service, customers must use quorum queues. As recommended by the RabbitMQ community, any workload using transactions or classic mirrored queues should switch to quorum queues. In many cases, this can be done with a minor code change when configuring a queue. 
    • We must note that currently, a reduced feature set is provided by quorum queues (e.g., dynamic queue names, TTL, and message priority are yet not available).
  • Usage of classic queues: 
    • To support higher-throughput “transient” workloads, customers are free to continue using classic transient queues. By default, these queues will be mirrored across three nodes, but messages are not written to disk. However, these queues are aimed for transient workloads, and we will favor availability over consistency for this queue type. Any queue found in an “undefined” (or leaderless) state will be automatically deleted and cannot be recovered. It is the responsibility of the customer to recreate such a queue.
    • Given the reduced feature set of quorum queues, we will allow the usage of classic mirrored durable queues, but with certain disclaimers. Nevertheless, because of the known RabbitMQ limitations, we highly encourage customers to avoid using classic mirrored queues. In contrast to previous RabbitMQ versions, our focus for classic mirrored queues will be on service availability over data consistency. As a result, when synchronization issues occur with classic mirrored queues, data may be lost—the system prioritizes availability over consistency. Like with transient queues, any classic mirrored queue found in an “undefined” (or leaderless state) will be automatically deleted and cannot be recovered. It is the responsibility of the customer to recreate such a queue.
  • With RabbitMQ 3.8, we will change the network partition handling strategy from “pause-minority” to “autoheal.” In addition, we will change the ha-promote-on-shutdown policy key from “when-synced” to “always.” These changes take effect on the service-availability over data-consistency approach for classic mirrored queues as described above. For details, see the RabbitMQ documentation

Given that Messages for RabbitMQ 3.7 is End of Life on IBM Cloud in September 2020, please check out how to upgrade right away

Get started with IBM Messages for RabbitMQ today! 

More from Cloud

Enhance your data security posture with a no-code approach to application-level encryption

4 min read - Data is the lifeblood of every organization. As your organization’s data footprint expands across the clouds and between your own business lines to drive value, it is essential to secure data at all stages of the cloud adoption and throughout the data lifecycle. While there are different mechanisms available to encrypt data throughout its lifecycle (in transit, at rest and in use), application-level encryption (ALE) provides an additional layer of protection by encrypting data at its source. ALE can enhance…

Attention new clients: exciting financial incentives for VMware Cloud Foundation on IBM Cloud

4 min read - New client specials: Get up to 50% off when you commit to a 1- or 3-year term contract on new VCF-as-a-Service offerings, plus an additional value of up to USD 200K in credits through 30 June 2025 when you migrate your VMware workloads to IBM Cloud®.1 Low starting prices: On-demand VCF-as-a-Service deployments begin under USD 200 per month.2 The IBM Cloud benefit: See the potential for a 201%3 return on investment (ROI) over 3 years with reduced downtime, cost and…

The history of the central processing unit (CPU)

10 min read - The central processing unit (CPU) is the computer’s brain. It handles the assignment and processing of tasks, in addition to functions that make a computer run. There’s no way to overstate the importance of the CPU to computing. Virtually all computer systems contain, at the least, some type of basic CPU. Regardless of whether they’re used in personal computers (PCs), laptops, tablets, smartphones or even in supercomputers whose output is so strong it must be measured in floating-point operations per…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters