Tanzu RabbitMQ OVA release notes include detailed release information for the Tanzu RabbitMQ OVA version 1.4.x, 1.5.x, 3.13.x, and 4.0 releases.

Important Notes before Continuing

  1. Tanzu RabbitMQ OVA 4.0 is the latest major commmercial release (Tanzu RabbitMQ OVA 4.0.1 is it's latest patch). It includes the open source RabbitMQ 4.0.1 package. This release is loaded with new features and functions, find out more below.

  2. The Tanzu RabbitMQ OVA 3.13.6 patch release includes open-source RabbitMQ 3.13.6. Note, there were no commercial Tanzu RabbitMQ OVA 3.13.4 or 3.13.5 patch releases.

  3. VMware Tanzu RabbitMQ OVA was formerly known as VMware RabbitMQ OVA. To avoid confusion, all releases listed in this release notes information are referred to using the current product offering name VMware Tanzu RabbitMQ OVA. If the specific release that you are using is called VMware RabbitMQ OVA and it is referred to as VMware Tanzu RabbitMQ OVA in these release notes, note that this is the same product offering, its naming has just varied over time. Tanzu RabbitMQ OVA files are available for download from the Broadcom Support Portal. For instructions, go to Downloading the VMware Tanzu RabbitMQ OVA Files documentation.

  4. You can also avail of documentation for the Open Source RabbitMQ product. As the Tanzu RabbitMQ OVA product offering is built from the open source RabbitMQ product, open source RabbitMQ documentation is a core part of the Tanzu RabbitMQ OVA documentation. When you are using this Tanzu RabbitMQ OVA documentation, you will be redirected to the open source RabbitMQ documentation as required.

VMware Tanzu RabbitMQ OVA Release 4.0

VMware Tanzu RabbitMQ OVA Release 4.0.1

VMware Tanzu RabbitMQ OVA 4.0.1 contains the following packages and changes:

Open-source RabbitMQ 4.0.1 Changes

Open-source RabbitMQ 4.0 is a new major release. Note that it is open-source RabbitMQ 4.0.1 that is packaged in the commercial VMware Tanzu RabbitMQ OVA 4.0.1 release. For more details about open-source RabbitMQ 4.0.1, review the 4.0.1 release notes.

Khepri

Khepri, the new storage backend for RabbitMQ metadata is the most significant change in this release. With the introduction of Khepri, two backends are now supported: Mnesia (the existing and default one) and Khepri. Both Mnesia and Khepri store users, permissions, vhosts, routes/bindings, topics, exchanges, parameters, and queue metadata. Khepri is based on the proven Raft protocol which is already used in quorum queues. The semantics of what to do when a partition occurs are well defined and not configurable with Khepri, which makes RabbitMQ even more robust when configured for high availability. Khepri is also more resilient to network outages across clusters. For more information, go to Khepri documentation. You can opt-in to use Khepri.

AMQP 1.0 becomes a Native Protocol

AMQP 1.0 becomes a native protocol in RabbitMQ. The AMQP 1.0 plugin, which was the previous mechanism used to introduce AMQP 1.0 into RabbitMQ is now removed, support for AMQP 1.0 is now enabled by default in RabbitMQ.

Go to AMQP 1.0 documentation to learn more or review these blogs:

  • A description of AMQP 1.0 and the history of different AMQP versions supported in RabbitMQ over time are included in the Native AMQP 1.0 blog post.
  • The major benefits of AMQP flow control are described in Ten Benefits of AMQP 1.0 Flow Control.
  • The significant performance and scalability improvements with AMQP 1.0 in RabbitMQ 4.0 compared to AMQP 1.0 in RabbitMQ 3.13 are explained in AMQP 1.0 Benchmarks.

Quorum Queue Features

Tanzu RabbitMQ OVA 4.0 includes the following new quorum queue features:

  • Message priorities, which is a highly sought after feature by RabbitMQ users is now here.
  • Consumer priorities combined with Single Active Consumer: In 4.0, quorum queues will take the consumer priority into account when selecting the single active consumer.
  • The default delivery limit is now set to 20 attempts. Previously, the limit was not set, quorum queues would keep attempting to deliver a message until the message was either acknowledged or discarded by the consumer. For more information, go to Configuring the Limit
  • Faster recovery of long queues.

You can also review the RabbitMQ 4.0: New Quorum Queue Features blog to learn more.

Warm Standby Replication Enhancements

  • You can now configure the upstream (primary) cluster to replicate Shovel and Federation runtime parameters on the downstream (standby) cluster. You must opt-in and select the vhosts to replicate the runtime parameters. For instructions, go to Optional: Configuring Schema Replication for Shovel and Federation Plugins.

  • Warm Standby Replication can be enabled for a group of virtual hosts using a regular expression:

   # virtual host that match ^multi_dc will have WSR enabled
   standby.replication.vhosts.vhost_selector = ^multi_dc

This method of virtual host selection is an alternative to virtual host tagging, which is still supported.

VMware Tanzu RabbitMQ OVA Release 3.13

VMware Tanzu RabbitMQ OVA Release 3.13.6

VMware Tanzu RabbitMQ OVA 3.13.6 contains the following packages and changes:

  • Open-source RabbitMQ 3.13.6
  • Erlang 26.2.5

Open-source RabbitMQ 3.13.6 Changes

Open-source RabbitMQ version 3.13.6 is a maintenance release in the 3.13.x release series.

For details on the changes in the core broker and so on, review the 3.13.6 release notes.

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

VMware Tanzu RabbitMQ OVA Release 3.13.3

VMware Tanzu RabbitMQ OVA 3.13.3 contains the following packages and changes:

Important

While this section is for the VMware Tanzu RabbitMQ OVA 3.13.3 release, it is important to know that a Tanzu RabbitMQ version 3.13.3.1 build is released after the OVA 3.13.3 release. The v3.13.3.1 build includes the latest OpenSSH package, which is a fix for CVE-2024-6387. If you are using the VMware Tanzu RabbitMQ 3.13.3 OVA, you can run tdnf update openssh to update the OpenSSH package or you can download the 3.13.3.1 OVA build from the Broadcom Support Portal. Follow the Download the Tanzu RabbitMQ OVA Image instructions, for the step to select your specific release, select 3.13.3.1.

Open-source RabbitMQ 3.13.2/3.13.3 Changes

Open-source RabbitMQ 3.13.2 and 3.13.3 are maintenance releases in the 3.13.x release series.

For details on the changes in the core broker, CLI tools, Management Plugin, and so on, review the 3.13.2 and 3.13.3 release notes.

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

Warm Standby Replication Improvements

The following Warm Standby Replication improvements are now available in the 3.13.3 Tanzu RabbitMQ OVA release.

  • 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, go to Warm Standby Replication Documentation, Method 1.
  • OAuth2 support for Warm Standby Replication synchronization: This 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 this 3.13.3 Tanzu RabbitMQ OVA release 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 setup FIPS compliance (which is built into Erlang) also. Now with the Tanzu RabbitMQ OVA 3.13 release, this FIPS configuration is provided ‘out of the box’.

Note

If you are using FIPS, you must pull the FIPS variant images from the Broadcom Support Portal. For instructions on how to get those images, go to Download the Tanzu RabbitMQ OVA Image documentation.

Support for MQTT 5.0

The previous 1.5.x releases of Tanzu RabbitMQ OVA included some significant improvements to the performance of the MQTT (Message Queuing Telemetry Transport) protocol, which is used extensively in IoT applications. For more details, refer to this blog.

RabbitMQ now supports MQTTv5 and significantly more connections per node. MQTT 5.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 3.1.1.

For a deeper dive into MQTT 5.0 support, its specifics with RabbitMQ, and the list of features you can avail of, go through the MQTT 5.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 this Tanzu RabbitMQ OVA 3.13.3 release, users can filter a stream. This feature lightens the load on client applications while at the same time 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. Visit the Stream Filtering documentation for more information.

The Introduction of Message Containers

Message containers are now introduced in the VMware Tanzu RabbitMQ OVA 3.13.3 release. This change is not obvious to users, it is an internal update in the way messages are handled internally. Why are they introduced? RabbitMQ was originally built as an AMQP 0-9-1 broker. However, over the years, support for AMQP 1.0, MQTT, STOMP, and streams was added, which has led to internal message format conversions since different protocols have mostly similar concepts, but differ in the details such as available data types.

Message containers use the AMQP 1.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 0.9.1. Previously all non AMQP 0.9.1 messages were handled via a translation layer which 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, Obviously 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 being used. 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 VMware Tanzu RabbitMQ OVA become even more flexible and has the potential to adopt many more protocols in the future.

New Experimental Metadata Database: Khepri

This 3.13.3 release of Tanzu RabbitMQ OVA is an important milestone in the roll out plan for a new storage backend for RabbitMQ metadata: Khepri. It is designed to replace the current Mnesia metadata store in a future release. This should significantly improve RabbitMQ's tolerance to network partitions. Once Khepri is in use, there will be 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 this 3.13.3 release, users can try out Khepri but note that Mnesia is still the default metadata store until Khepri is implemented in a future Tanzu RabbitMQ OVA release.

Improvements to the Memory Footprint

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

VMware Tanzu RabbitMQ OVA Release 1.5

VMware Tanzu RabbitMQ OVA Release 1.5.3

VMware Tanzu RabbitMQ 1.5.3 contains the following packages and changes:

  • RabbitMQ 3.12.12
  • Erlang 25.3.2.7

Open-source RabbitMQ 3.12.12 Changes

Open-source RabbitMQ version 3.12.12 is a maintenance release in the 3.12.x release series.

Important

The VMware Tanzu RabbitMQ 1.5.3 release includes a RabbitMQ version that is based on the RabbitMQ open-source version 3.12.12 so similiar to the previous VMware Tanzu RabbitMQ 1.5.2, 1.5.1, and 1.5.0 releases, the same scenario applies to feature flags. Open-source RabbitMQ 3.12.x packages require all feature flags from the 3.11.x release series to be turned on before upgrading so you must turn on feature flags now on all RabbitMQ clusters that you want to upgrade from VMware Tanzu RabbitMQ version 1.4.3. If you are coming from a VMware Tanzu RabbitMQ version that is before 1.4.3 (such as version 1.4.2) and you want to upgrade to VMware Tanzu RabbitMQ version 1.5.3, you must upgrade to VMware Tanzu RabbitMQ version 1.4.3 first.

Core Server: Bug Fixes

  • Build up of Erlang processes: In RabbitMQ environments with a large number of quorum queues, there are a large number of Erlang processes as a result. You may get a build-up of these Erlang processes in your environment. This build should be temporary but if there are a large number of them, it could take a while to clear. If these processes are not cleared before the next round of operations occur then your number of processes is now larger again, which means there could be a continuing build-up of processes all the time. This issue should now be fixed. Refer to Github pull request 10242 for more information.
  • Propagate all credentials to http backend to ensure successful login to RabbitMQ: Parameters such as client_id that are required during the authentication of MQTT were not passed to the authentication backends used to authenticate the user. As a result, when MQTT users accessed RabbitMQ via the MQTT protocol, they could not login because the client_id parameter that was used during the authentication to open an MQTT connection was not passed down to the http authentication backend that RabbitMQ uses to authenticate the user. The configured http backend expected the client_id parameter. This issue should now be resolved. Refer to Github pull request 10230 for more information.
  • A RabbitMQ node now waits for any changes in the state of the feature flags to be complete before the node shuts down. Refer to Github pull request 10279 for more information.

Stream Plugin: Bug Fixes

  • Return expected internal error code in stream metadata lookup: When a RabbitMQ node is unavailable, this fix ensures the metadata stream protocol operation does not fail. Refer to Github pull request 10277 for more information.

  • Allow MQTT QoS 0 subscribers to reconnect: In the VMware Tanzu RabbitMQ OVA 1.5.2 release (and previous releases), the following issue existed:

    1. An MQTT client connects to a RabbitMQ node with CleanSession=true and subscribes with QoS=0. (Internally, RabbitMQ creates a queue with a rabbit_mqtt_qos0_queue type).
    2. The node crashes, that is, it does not shut down cleanly.
    3. The MQTT client re-connects to a different RabbitMQ live node.
    4. The MQTT client re-subscribes with QoS=0.

    Step 4 fails with a Failed to declare queue <queue name>: {absent, AmqQueue, nodedown} error message. This issue should now be fixed in this VMware Tanzu RabbitMQ OVA 1.5.3 release. Clients can re-connect and re-subscribe to a RabbitMQ live node if the original node hosting the MQTT connection crashed. Refer to Github pull request 10244 for more information.

CLI Tools: Bug Fix

Some CLI commands (like rabbitmq-diagnostics observer) were failing to accept input since this Github pull request was included in the open-source RabbitMQ 3.12.11 release. This issue should now be fixed in the current RabbitMQ 3.12.12 release. Refer to Github pull requests 10270 and 10258 for more information.

For more information about other features and fixes introduced in open-source RabbitMQ 3.12.12, review the release notes or to review release notes for open-source RabbitMQ versions from 3.12.10 (3.12.10 was the RabbitMQ version that was included in the previous Tanzu V1.5.2 OVA release) to the current 3.12.12, go here and select the particular release notes version that you want.

VMware Tanzu RabbitMQ OVA Release 1.5.2

VMware Tanzu RabbitMQ 1.5.2 contains the following packages and changes:

  • RabbitMQ 3.12.10
  • Erlang 25.3.2.7

Open-source RabbitMQ 3.12.10 Changes

Open-source RabbitMQ version 3.12.10 is a maintenance release in the 3.12.x release series.

Important

The VMware Tanzu RabbitMQ 1.5.2 release includes a RabbitMQ version that is based on the RabbitMQ open-source version 3.12.10 so similiar to the previous VMware Tanzu RabbitMQ 1.5.1 and 1.5.0 releases, the same scenario applies to feature flags. Open-source RabbitMQ 3.12.x packages require all feature flags from the 3.11.x release series to be turned on before upgrading so you must turn on feature flags now on all RabbitMQ clusters that you want to upgrade from VMware Tanzu RabbitMQ version 1.4.3. If you are coming from a VMware Tanzu RabbitMQ version that is before 1.4.3 (such as version 1.4.2) and you want to upgrade to VMware Tanzu RabbitMQ version 1.5.2, you must upgrade to VMware Tanzu RabbitMQ version 1.4.3 first.

Shovel Plugin Enhancement:

Previously, after upgrading to 3.12.9 from 3.12.6 or an older version, two Shovels were started. Two Shovels running concurrently can still transfer messages but because they act as competing consumers (and publishers), message ordering in the target queue is affected.

Now with this enhancement, if you upgrade from 3.12.6 to a newer version of RabbitMQ such as 3.12.9 or 3.12.10 this scenario no longer occurs. Refer to Github pull request 9965 for more information.

For more information about other features and fixes introduced in open-source RabbitMQ 3.12.10, review the release notes or to review release notes for open-source RabbitMQ versions from 3.12.4 (3.12.4 was the RabbitMQ version that was included in the previous VMware Tanzu RabbitMQ OVA V1.5.1 release) to the current 3.12.10, go here and select the particular release notes version that you want.

VMware Tanzu RabbitMQ OVA Release 1.5.1

VMware Tanzu RabbitMQ 1.5.1 contains the following packages and changes:

  • RabbitMQ 3.12.4
  • Erlang 25.3.2.5

Open-source RabbitMQ 3.12.4 Changes

Open-source RabbitMQ version 3.12.4 is a maintenance release in the 3.12.x release series.

Important

The VMware Tanzu RabbitMQ 1.5.1 release includes a RabbitMQ version that is based on the RabbitMQ open-source version 3.12.4 so similiar to the previous VMware Tanzu RabbitMQ 1.5.0 release, the same scenario applies to feature flags. Open-source RabbitMQ 3.12.x packages require all feature flags from the 3.11.x release series to be turned on before upgrading so you must turn on feature flags now on all RabbitMQ clusters that you want to upgrade from VMware Tanzu RabbitMQ version 1.4.3. If you are coming from a VMware Tanzu RabbitMQ version that is before 1.4.3 (such as version 1.4.2) and you want to upgrade to VMware Tanzu RabbitMQ version 1.5.1, you must upgrade to VMware Tanzu RabbitMQ version 1.4.3 first.

Core Server Bug Fix:

Consumer churn on quorum queues can result in some messages not being delivered to consumers in some cases. This issue mostly affected queue federation links. Refer to Github pull request 9158 for more information.

Management Plugin Bug Fix:

Quorum queue replica management operations over the HTTP API can now be turned off (deactivated). This functionality is useful in environments where replica management is completed by the platform team and tooling, and should not be exposed to cluster users. Refer to Github pull request 9151 for more information.

Federation Plugin Bug Fix:

Queue federation links that connected quorum queues could get stuck (stop transferring messages even when there were no other consumers on the upstream). Refer to Github pull request 9158 for more information.

LDAP Plugin (AuthN/AuthZ Backend) Bug Fix:

Previously, the LDAP plugin did not interpolate values with non-ASCII characters correctly. Refer to Github issue 9059 for more information.

OVA Operating System Specific Settings:

The LimitNOFILE parameter is now set to the default value 65536.

For more information about other features and fixes introduced in open-source RabbitMQ 3.12.4, review the release notes or to review release notes for open-source RabbitMQ versions from 3.12.2 to the current 3.12.4, go here and select the version that you want to display its release notes.

VMware Tanzu RabbitMQ OVA Release 1.5.0

VMware Tanzu RabbitMQ 1.5.0 contains the following packages and changes:

  • RabbitMQ 3.12.2
  • Erlang 25.3.2.3

Open-source RabbitMQ 3.12.2 Changes

Open-source RabbitMQ version 3.12.2 is a maintenance release in the 3.12.x release series.

Important

The VMware Tanzu RabbitMQ 1.5.0 OVA release includes a RabbitMQ version that is based on the RabbitMQ open-source version 3.12.2. Open-source RabbitMQ 3.12.x packages require all feature flags from the 3.11.x release series to be turned on before upgrading so you must turn on feature flags now on all RabbitMQ clusters that you want to upgrade from VMware Tanzu RabbitMQ OVA version 1.4.3. If you are coming from a VMware Tanzu RabbitMQ OVA version that is before 1.4.3 (such as version 1.4.2) and you want to upgrade to VMware Tanzu RabbitMQ OVA version 1.5.0, you must upgrade to VMware Tanzu RabbitMQ OVA version 1.4.3 first.

Core Server: Bug Fixes

  • In very rare conditions, recovering queues when a node is restarted can cause an exception. Refer to Github issue 8746 for more information.
  • file_handle_cache operations are now safer when handling non-existent keys. Refer to Github issue 8784 for more information.
  • Fixed a potential resource leak in at-least-once dead lettering from quorum queues. Refer to Github pull request 8799 for more information.

CLI Tools: Enhancements

A new command, rabbitmqctl deactivate_free_disk_space_monitoring, can be used to (temporarily or permanently) deactivate free disk space monitoring on a node. To re-activate it, use rabbitmqctl activate_free_disk_space_monitoring. Refer to Github pull request 8801 for more information.

AMQP 1.0 Plugin: Bug Fixes

AMQP 1.0 clients that try to publish a message in a way that results in that message not being routed anywhere are now notified with a status "released" for that message. Refer to Github issue 7823 for more information.

Prometheus Plugin: Enhancements

  • Prometheus scraping API endpoints now support optional authentication. Refer to the Github pull request 8661 for more information.
  • The Prometheus plugin now filters out values that are undefined or NaN by excluding these values from the API endpoint response. Previously, if a metric was not computed for any reason (for example: free disk space monitor was turned off on the node), its value could end up being rendered as undefined or NaN, which are two values that Prometheus scrapers cannot handle (for numerical types such as gauges). Refer to Github issue 8740 for more information.

Management Plugin: Bug Fixes

Previously, it was not possible to close a table column selection pane on screens with minimal vertical space. Refer to Github issue 8660 for more information.

STOMP Plugin: Bug Fixes

The plugin now enforces a maximum STOMP frame size. Frames larger than the maximum STOMP frame size size are rejected. The default maximum size is 4 MiB. It can be increased or decreased. To increase the maximum supported STOMP frame size to 10 MiB, set the value: stomp.max_frame_size = 10485760. To decrease the default 4 MiB to 2 MiB, set the value stomp.max_frame_size = 2097152.

Shovel Plugin: Bug Fixes

Shovel stop when its destination (target) does not exist. Such shovels are then periodically restarted to retry. Refer to Github issue 8697 for more information.

Web MQTT Plugin: Enhancements

It is now possible to opt in to deactivate file handle cache use in the plugin by setting web_mqtt.use_file_handle_cache = false. Refer to Github pull request 8790 for more information.

Web STOMP Plugin: Enhancements

It is now possible to opt in to deactivate file handle cache use in the plugin by setting web_stomp.use_file_handle_cache = false. Refer to Github pull request 8790 for more information.

For more information about other features and fixes introduced in open-source RabbitMQ 3.12.2, review the release notes.

Open-source RabbitMQ 3.12.0 Features

Open Source RabbitMQ 3.12.0 is a new feature release which RabbitMQ 3.12.2 is part of. RabbitMQ 3.12.0 includes new features, optimizations, and also implements functionality where a number of feature flags are now mandatory.

The following lists the user-facing areas that have biggest improvements:

  • Optimizations for both quorum and classic queues: improved throughput, lower throughput variability, lower latency, and lower memory footprint.
  • More mature and efficient implementation of (non-mirrored) classic queues v2 (CQv2).
  • Classic queue lazy and non-lazy modes no longer apply: classic queues v2 always behave very similarly to the lazy mode in earlier release series, that is, actively moving data to disk and only keeping a subset of data in memory.
  • Significantly reduced MQTT and Web MQTT memory footprint per connection.
  • OAuth 2, OIDC, and IDP support.
  • More configuration options for the OAuth 2 plugin.

This release also includes many internal API improvements in preparation for the upcoming new major RabbitMQ 4.0 release (coming in the future) with Khepri. For more information, review the 3.12.0 release notes.

Dependency Upgrades

ra was upgraded to 2.6.3

VMware Tanzu RabbitMQ OVA Releases 1.4

VMware Tanzu RabbitMQ OVA Release 1.4.5

VMware Tanzu RabbitMQ 1.4.5 contains the following packages and changes:

  • RabbitMQ 3.11.25
  • Erlang 25.3.2.7

Open-source RabbitMQ 3.11.25 Changes

RabbitMQ 3.11.25 is a maintenance release in the 3.11.x release series.

Core Server Bug Fix:

A fix is implemented to handle the autoheal winner_waiting state with a chosen winner notification received. This solution handles this case in the same way as all other {winner_is, Winner} messages, it restarts the loser and updates the autoheal state to avoid crashing the node monitor process. Refer to Github pull request 9819 for more information.

Core Server Enhancement:

raft.segment_max_entries is now validated to prevent the value from overflowing its 16-bit segment file field. Maximum supported value is now 65535. Refer to Github pull request 9748 for more information.

Shovel Plugin Enhancement:

Much faster Shovel startup in environments where many shovels exist (one thousand or more). Refer to Github pull request 9800 for more information.

AMQP 1.0 Erlang Client Enhancement:

Previously, credentials could be logged in a small number of failure scenarios and only for Shovels that used AMQP 1.0. Now, shovels that use AMQP 1.0 will avoid logging sensitive data in case in certain failure scenarios. Refer to Github pull request 9778 for more information.

For more information about other features and fixes introduced in open-source RabbitMQ 3.11.0, review the release notes or to review release notes for open-source RabbitMQ versions from 3.11.22 (3.11.22 was the RabbitMQ version that was included in the previous VMware Tanzu RabbitMQ OVA V1.4.4 release) to the current 3.11.25, go to here and select the particular release notes version that you want.

VMware Tanzu RabbitMQ OVA Release 1.4.4

VMware Tanzu RabbitMQ 1.4.4 contains the following packages and changes:

  • RabbitMQ 3.11.22
  • Erlang 25.3.2.5

Open-source RabbitMQ 3.11.22 Changes

RabbitMQ 3.11.22 is a maintenance release in the 3.11.x release series.

Management Plugin Bug Fix:

Quorum queue replica management operations over the HTTP API can now be turned off (deactivated). This functionality is useful in environments where replica management is completed by the platform team and tooling, and should not be exposed to cluster users. Refer to Github pull request 9151 for more information.

LDAP Plugin (AuthN/AuthZ Backend) Bug Fix:

Previously, the LDAP plugin did not interpolate values with non-ASCII characters correctly. Refer to Github issue 9059 for more information.

OVA Operating System Specific Settings

The LimitNOFILE parameter is now set to the default value 65536.

For more information about other features and fixes introduced in open-source RabbitMQ 3.11.0, review the release notes or to review release notes for open-source RabbitMQ versions from 3.11.18 to the current 3.11.22, go to here and select the release notes file for the particular version you want.

VMware Tanzu RabbitMQ OVA Release 1.4.3

VMware Tanzu RabbitMQ 1.4.3 contains the following packages and changes:

  • RabbitMQ 3.11.18
  • Erlang 25.3
  • The command line tool rabbitmqadmin is removed from the VMware Tanzu RabbitMQ V1.4.3 OVA.

Open-source RabbitMQ 3.11.18 Changes

Open-source RabbitMQ version 3.11.18 is a maintenance release in the 3.11.x release series.

Core Server: Bug Fixes

  • Classic queues v1 (CQv1) that had a backlog of messages stored by RabbitMQ version 3.9 and earlier versions sometimes ran into an exception during queue index recovery after an upgrade to RabbitMQ version 3.10.x or any later series was completed. This issue is now resolved. Classic queues (CQv2) and queues without a backlog were not affected by this issue.
  • rabbitmq-upgrade drain failed with an exception in environments where the management plugin (HTTP API) plugin listener was bound to a specific interface. This issue is now resolved.

OAuth 2 Plugin: Enhancements

The OAuth 2 plugin now accepts JWT tokens without a scope. These tokens are useful only when the plugin is used exclusively for authentication and not authorization.

For more information about other features and fixes introduced in open-source RabbitMQ 3.11.0, review the release notes or to review release notes for open-source RabbitMQ versions from 3.11.11 to the current 3.11.18, go to here and select the release notes file for the particular version you want.

VMware Tanzu RabbitMQ OVA Release 1.4.2

VMware Tanzu RabbitMQ 1.4.2 contains the following packages and changes

  • RabbitMQ 3.11.11
  • Erlang 25.2

RabbitMQ 3.11.11 Changes

RabbitMQ version 3.11.11 is a maintenance release in the 3.11.x release series.

Core Server: Bug Fixes

  • Previously, customers using streams who switched between being active and inactive, or temporarily became very slow could become completely starved of deliveries. This meant that their message delivery rate could drop to 0 while other consumers did not have this problem. This issue is now resolved.
  • Previously, the memory of the stream coordinator process (rabbit_stream_coordinator) was reported asother. This issue is now resolved and the stream coordinator process memory footprint is now reported correctly (and classified differently).

Core Server: Enhancements

  • There is now a way to pre-configure users and their permissions for newly created virtual hosts:

    default_users.qa_user.vhost_pattern = qa.*
default_users.qa_user.tags = policymaker,monitoring
default_users.qa_user.password = fd237824441a78cd922410af4b83f0888186a8d7
default_users.qa_user.read = .*
default_users.qa_user.write = .*
default_users.qa_user.configure = .*

    This is primarily useful in environments where RabbitMQ is provided as a service but customers (clients) have control over virtual hosts.

STOMP Plugin

  • Consumers on /queue/ destinations that consume from streams can now specify the x-stream-max-segment-size-bytes setting using SUBSCRIBE frame headers.

etcd Peer Discovery Plugin

  • ETCD peer discovery ignored the TTL configuration provided by the user. This issue is now resolved.

For more information about other features and fixes introduced in the RabbitMQ 3.11.0, review the release notes or to review release notes for RabbitMQ versions from 3.11.8 to the current 3.11.11, go to here and select the release notes file for the particular version you want.

VMware Tanzu RabbitMQ OVA Release 1.4.1

VMware Tanzu RabbitMQ 1.4.1 contains the following packages and changes.

  • RabbitMQ 3.11.8
  • Erlang 25.2

RabbitMQ 3.11.8 Changes

RabbitMQ version 3.11.8 is a maintenance release in the 3.11.x release series. The main fixes in this release are:

Core Server

Stream throughput improvements are implemented for workloads, which have a lot of smaller size messages (messages less than 10 bytes).

CLI Tools Features

  • rabbitmqctl hash_password is a new command that produces a hashed value for the password that is provided.

  • rabbitmq-diagnostics check_port_connectivity now supports a new optional --address flag where the user can now enter an IP address for the node and test it's connectivity. Previously, only hostname resolution was allowed. This is useful when the target node is configured to only listen for connections on one interface but not others. The following example shows how to provide the IP address with the --address flag.

    rabbitmq-diagnostics check_port_connectivity --address 127.0.0.1
rabbitmq-diagnostics check_port_connectivity --address "::1"

Management Plugin

The bug fixes are:

  • Filtering users when using pagination in the RabbitMQ Management UI did not work as expected, this is now fixed.
  • Correctly formatted the JSON field value in the channel_details API response.

AMQP 1.0 Plugin

  • AMQP 1.0 connection churn was causing a memory leak, this is now fixed.

STOMP Plugin

  • STOMP client subscriptions to a destination that is an AMQP 0-9-1 exchange now creates an exclusive, auto-delete queue on an exchange. Previously, it only created an only auto-delete queue but it was not exclusive.

For more information about other features and fixes introduced in the RabbitMQ 3.11.0, review the release notes.

Known Issues and Limitations

Issue Description Release Found In
Some rabbitmq commands might not work as the PATH variable does not include OTP binaries. The workaround is to update the PATH variable to: PATH=/opt/broadcom/otp-26.2.5/bin:/opt/rabbitmq/sbin:$PATH 3.13.3
Networking information (IP address and DNS) set in the configuration wizard when the OVA is imported does not work after the virtual machine is started. For instructions to solve this issue, go to Networking Information populated in the Configuration Wizard while Importing the OVA does not work on the Virtual Machine in the Troubleshooting information. This issue will be resolved in a future VMware Tanzu RabbitMQ OVA version. 1.4.1
Warm Standby Replication: Users can now configure credentials using rabbitmq.conf. One limitation around this is these credentials are listed in rabbitmq.conf. A method for storing them in a suitable secret store will be implemented in a future VMware Tanzu RabbitMQ OVA release. Note, prior to the 3.13.3 release, this was not an issue because configuring credentials in rabbitmq.conf was only introduced in the 3.13 VMware Tanzu RabbitMQ OVA release. 3.13.3
Warm Standby Replication: When schema_definition_sync.downstream.locals.users.* is used (this feature is optional), the schema definition replication leaves warnings about failed permission import attempts in the downstream logs. You can ignore these warnings. This does not affect promoting the downstream (standby) cluster in any way. 3.13.3

Resolved Issues

Issue Description Release Found In Release Resolved In
Admin page does not render correctly in the RabbitMQ Management UI. There are errors with limits/users/virtual hosts. 1.4.1 1.4.2
Corrected an issue where changing the value of the standby.replication.operating_mode and restarting the node failed to fully adopt the intended mode. 1.4.3 and in 1.5.0 1.4.4 and in 1.5.1
Warm Standby Replication: When stream data on the upstream expires, downstream replication connections could run into an exception. releases prior to 3.13.6 3.13.6
Warm Standby Replication: Downstreams can fail to connect to upstreams in certain conditions. 3.13.3 3.13.6
check-circle-line exclamation-circle-line close-line
Scroll to top icon