View a markdown version of this page

RabbitMQ 4.3 - Amazon MQ
Breaking changes in RabbitMQ 4.3 on Amazon MQNew features and enhancements in RabbitMQ 4.3 on Amazon MQ

RabbitMQ 4.3

Amazon MQ now supports RabbitMQ 4.3 in the RabbitMQ 4 release series on the mq.m7g instance type across all supported instance sizes. RabbitMQ 4.3 introduces quorum queue enhancements, new exchange types, and completes the removal of several features that were deprecated in earlier 4.x releases. For more information about this release, see the RabbitMQ 4.3.0 release notes on the GitHub website.

Important

Amazon MQ only supports upgrading to RabbitMQ 4.3 from RabbitMQ 4.2. You cannot upgrade directly from RabbitMQ 3.13 to 4.3. If your broker is running RabbitMQ 3.13, you must first upgrade to RabbitMQ 4.2 before upgrading to 4.3.

Breaking changes in RabbitMQ 4.3 on Amazon MQ

The following open-source changes might impact your applications when upgrading to RabbitMQ 4.3. Review these changes before upgrading your broker.

  • Transient non-exclusive queues are rejected: Declaring a queue that is both non-durable and non-exclusive now returns an error. Amazon MQ for RabbitMQ 4.3 removed support for this feature. Use durable queues, exclusive queues, or durable queues with queue TTL on the RabbitMQ website instead.

  • Global QoS is rejected: Calling basic.qos with global=true now returns a channel error. Amazon MQ for RabbitMQ 4.3 removed support for this feature. Use per-consumer prefetch (global=false) instead. For more information about this change, see Removal of global QoS on the RabbitMQ website.

  • Classic queue v1 storage is removed: Declaring a queue with x-queue-version=1 now returns an error. Classic queue v2 is the only supported storage engine. Amazon MQ has enforced v2 since RabbitMQ 3.12, so existing queues are not affected.

  • Consumer timeout no longer applies to classic queues: Classic queues no longer evaluate consumer timeouts. If a consumer becomes stuck at the application level, RabbitMQ does not automatically redeliver messages. The consumer_timeout setting continues to apply to quorum queues. If your application relies on consumer timeout for classic queues, consider migrating to quorum queues or implementing application-level heartbeat checks. For more information about this change, see the RabbitMQ 4.3.0 release notes on the GitHub website.

New features and enhancements in RabbitMQ 4.3 on Amazon MQ

  • Quorum queue strict priority: Quorum queues now support strict priority ordering with up to 32 levels (0–31), enabled with the x-max-priority queue argument. Higher-priority messages are always delivered before lower-priority messages. This replaces the 2-level ratio-based delivery introduced in RabbitMQ 4.2. For more information about quorum queue priorities, see Quorum queue priorities on the RabbitMQ website.

  • Quorum queue delayed retry: Quorum queues support delayed retry with configurable increasing backoff. You can configure retry behavior by using queue arguments or policy keys (delayed-retry-type, delayed-retry-min, delayed-retry-max). For more information about quorum queues, see Quorum queues on the RabbitMQ website.

  • Granular consumer timeout for quorum queues: Consumer timeout can now be set per-consumer, per-queue, or by using a policy. This provides finer control than the previous broker-wide consumer_timeout setting.

  • Delivery limit changeable by using a policy: The quorum queue delivery limit can now be updated by using a policy without requiring queue redeclaration.

  • Consistent hash exchange (x-modulus-hash): The x-modulus-hash exchange type is now built into RabbitMQ core. This exchange type distributes messages across bound queues by using consistent hashing of the routing key, enabling workload sharding without client-side logic. For more information about consistent hash exchanges, see Consistent hash exchange on the RabbitMQ website.

Important

If you are upgrading from RabbitMQ 4.2, note the following change to message delivery. Existing messages with priorities previously mapped to high (≥5) or normal (0–4) are now delivered using strict ordering. As a result, lower-priority messages might be starved while higher-priority messages remain in the queue. RabbitMQ 4.2 used 2:1 ratio-based delivery, which guaranteed progress on normal-priority messages.