Tanzu RabbitMQ OCI 3.13

4.0 3.13

VMware Tanzu RabbitMQ OCI Release Notes

Last Updated February 26, 2025

These release notes include detailed version information for Tanzu RabbitMQ Container Image (OCI).

The Tanzu RabbitMQ OCI is available for download from the Broadcom Support Portal For instructions, see Downloading and Running the Tanzu RabbitMQ OCI.

Important notes before continuing

  • Tanzu RabbitMQ OCI v3.13 is the latest major commercial version. Tanzu RabbitMQ OCI v3.13.8 is the latest patch. There is a jump in version numbers to align the product version numbers between open-source RabbitMQ and commercial Tanzu RabbitMQ.

  • The latest patch for Tanzu RabbitMQ OCI v3.13 is v3.13.8. This patch matches the included open-source RabbitMQ version, which is also v3.13.8. There was no Tanzu RabbitMQ OCI v3.13.7 patch.

  • VMware Tanzu RabbitMQ OCI was formerly known as VMware RabbitMQ OCI. To avoid confusion, all versions listed in this topic are referred to by the current name VMware Tanzu RabbitMQ OCI (Tanzu RabbitMQ OCI for short).

  • Because Tanzu RabbitMQ OCI is built from open-source RabbitMQ, open-source RabbitMQ documentation is a core part of the Tanzu RabbitMQ OCI documentation. This documentation directs you to the open-source RabbitMQ documentation where relevant.

Tanzu RabbitMQ OCI v3.13

The following sections describe changes in v3.13.

Tanzu RabbitMQ OCI v3.13.8

Tanzu RabbitMQ OCI v3.13.8 contains the following packages and changes:

  • Open-source RabbitMQ v3.13.8
  • Erlang v26.2.5

Open-source RabbitMQ v3.13.8 changes

Open-source RabbitMQ v3.13.8 is a maintenance release in the v3.13.x release series.

For information about the changes in the core broker and so on, review the v3.13.8 release notes.

To review the release notes for the entire v3.13.x release series, see the open-source RabbitMQ release notes and then select the relevant version.

Tanzu RabbitMQ OCI v3.13.6

Tanzu RabbitMQ OCI v3.13.6 contains the following packages and changes:

  • Open-source RabbitMQ v3.13.6
  • Erlang v26.2.5

Open-source RabbitMQ v3.13.6 changes

Open-source RabbitMQ v3.13.6 is a maintenance release in the v3.13.x release series.

For information about the changes in the core broker and so on, review the v3.13.6 release notes.

To review the release notes for the entire v3.13.x release series, go to all open-source RabbitMQ release notes and choose the specific version of the release notes that you want.

Tanzu RabbitMQ OCI v3.13.3

Tanzu RabbitMQ OCI v3.13.3 contains the following packages and changes:

Open-source RabbitMQ v3.13.2 and v3.13.3 changes

Open-source RabbitMQ v3.13.2 and v3.13.3 are maintenance releases in the v3.13.x release series.

For information about the changes in the core broker, CLI tools, Management plug-in, and so on, see the v3.13.2 and v3.13.3 release notes.

To review the release notes for the entire v3.13.x release series, go to all open-source RabbitMQ release notes and then select the relevant version of the release notes.

Warm Standby Replication improvements

The following Warm Standby Replication improvements are now available in Tanzu RabbitMQ OCI v3.13.3.

  • Users can now configure connection endpoints and credentials using rabbitmq.conf.
  • Streams can now be replicated.
  • You can view Warm Standby Replication metrics from the replication tabs in the RabbitMQ Management UI. Users can monitor the upstream (primary) and downstream (standby) clusters in a Warm Standby Replication configuration and check the status of both message and schema replication. For instructions, see Warm Standby Replication Method 1.
  • OAuth2 support for Warm Standby Replication synchronization enhances the security of data links between the upstream (primary) and downstream (standby) cluster, used in Warm Standby Replication, by using a more secure OAuth 2.0 authentication mechanism.
  • New CLI commands are introduced such as the rabbitmqctl promote_warm_standby command, which completes all promotion tasks in one step.
  • Bug fixes.

FIPS compliance

One of the key features exclusive to Tanzu RabbitMQ OCI v3.13.3 is compliance with the Federal Information Processing Standard (FIPS) 140-2. This compliance provides another level of security to RabbitMQ messaging using OpenSSL 3.

Security of financial and governmental systems is essential for organizations. Setting up the correct configuration can be challenging enough without having to set up FIPS compliance (which is built into Erlang) also. Now with Tanzu RabbitMQ OCI v3.13.3, this FIPS configuration is provided out of the box.

Support for MQTT v5.0

The previous v1.5 patches of Tanzu RabbitMQ OCI included some significant improvements to the performance of the MQTT (Message Queuing Telemetry Transport) protocol, which is used extensively in IoT applications. For more information, see the RabbitMQ blog.

RabbitMQ now supports MQTTv5 and significantly more connections per node. MQTT v5.0 provides improved session management, support for user properties, and extended error-reporting. More fine-grained control over message properties and behaviors is also supported, which makes it a more versatile and extensible protocol compared to MQTT v3.1.1.

For a deeper dive into MQTT v5.0 support, its specifics with RabbitMQ, and the list of features you can use, see the MQTT v5.0 blog post.

Filtering for RabbitMQ streams

Since the launch of streams in RabbitMQ, there is a steady growth in the adoption of this highly performant message transport mechanism. Streams not only provide the ability to route high volumes of data, they can also be partitioned into topics to make the consumption easier for client applications using super streams.

Now in Tanzu RabbitMQ OCI v3.13, users can filter a stream. This feature lightens the load on client applications while saving network bandwidth. In high throughput message topologies, it is common for microservices to become overburdened and in extreme cases cease to be micro at all. Filtering for streams is very helpful in this type of application. For more information, see the RabbitMQ documentation.

The Introduction of Message Containers

RabbitMQ was originally built as an AMQP 0-9-1 broker. However, over the years, support for AMQP v1.0, MQTT, STOMP, and streams was added. This has led to internal message format conversions because different protocols have mostly similar concepts, but differ in the details, such as available data types.

Message containers use the AMQP v1.0 data format. Message containers modernize internal message representation with today’s multi-protocol assumptions and makes all the conversions between protocols explicit. Message containers offer greater flexibility for users looking to leverage protocols other than AMQP v0.9.1.

Previously all non-AMQP v0.9.1 messages were handled by using a translation layer that increased the processing overhead and had the potential to lose some metadata. With message containers, messages are wrapped and preserved throughout the routing of Tanzu RabbitMQ and only reconstructed back into their original format when consumed.

Metadata is preserved where possible. If consuming in a different protocol to that which published a message, a compromise in metadata mapped is needed. Integrating event-driven architectures across disparate systems can be very complex, especially if earlier versions of protocols (such as MQTTv3) are in use.

Message containers allow users to consume messages from earlier versions of protocols and integrate them into a more modern microservice architecture without having to rewrite consuming clients from the beginning.

To summarize, message containers have helped Tanzu RabbitMQ OCI become even more flexible, and has the potential to adopt many more protocols in the future.

New experimental metadata database: Khepri

Tanzu RabbitMQ OCI v3.13.3 is an important milestone in the rollout plan for Khepri, a new storage back end for RabbitMQ metadata. It is designed to replace the current Mnesia metadata store in a future version. This should significantly improve RabbitMQ’s tolerance to network partitions.

After Khepri is in use, there is no partition-handling strategy configuration (pause_minority, autoheal, and so on). Just like quorum queues, Khepri is also based on the Raft protocol therefore the semantics of what to do when a partition occurs are well defined and not configurable. In v3.13.3 users can try out Khepri, but Mnesia is still the default metadata store until Khepri is implemented in a future Tanzu RabbitMQ OCI version.

Improvements to the memory footprint

The memory footprint for the robust quorum queue and conventional classic queues v2 is greatly improved in Tanzu RabbitMQ v3.13.3. As a result of these improvements, the benefits include better resource efficiency, cost savings, enhanced performance, and greater stability overall.