Skip to main content
Version: Latest

Known Limitations

This page describes concerns and limitations that should be considered when allocating resources to a9s Messaging plans, as well as other known issues.

Caveats regarding Backups​

caution

When creating a backup for a9s Messaging, please note that only the queue definitions are stored. The actual messages within the queues are not saved, as this service is designed for non-persistent queues.

When restoring a backup, any missing queues will be added to the service. Meanwhile, the existing queues and their corresponding data, that existed before the backup was created, will be preserved.

Object Size Limit​

a9s Messaging's underlying RabbitMQ service has a hard limit of 16 MiB for object sizes, however, publishing messages anywhere near that size is discouraged if there is uncertainty over the Virtual Machine's available resources being large enough to handle it. The reason behind this is that if the VM is not big enough, such messages may cause the underlying service to misbehave when the usage reaches a level comparable to the available resources. This happens because any message of a size close to it pins massive RAM in every queue, multiplies disk I/O, and can block connections long enough to trigger false fail-overs. Therefore, sluggish, or even briefly unavailable, Service Instances will be noticeable well below the limit. For more information, please check RabbitMQ limits documentation.

Quorum Queue Delivery Limit​

caution

Starting with RabbitMQ 4.3, quorum queues no longer have a default delivery_limit. In previous versions, the default was 20, meaning messages that were rejected and requeued more than 20 times would be dropped (or dead-lettered, if a dead-letter exchange was configured).

With the default limit removed, messages that are repeatedly rejected and requeued will be redelivered indefinitely. This can lead to stuck consumers or excessive resource usage if the application does not handle poison messages properly.

It is strongly recommended to set an explicit delivery-limit via a policy or as a queue argument on all quorum queues.

Consumer Timeout and Classic Queues​

caution

Starting with RabbitMQ 4.3, the consumer_timeout setting is no longer evaluated for classic queues. This means consumers of classic queues that hold messages without acknowledgement will no longer be automatically disconnected after the configured timeout period.

Applications that relied on the consumer timeout to detect and disconnect stalled consumers on classic queues should implement their own timeout logic, or consider migrating to quorum queues, where consumer timeouts are still enforced.

The consumer_timeout custom parameter continues to apply to quorum queues and streams.

Deprecated Features​

Starting with RabbitMQ 4.3, several features were deprecated. They will continue to work for RabbitMQ 4.3, but they will probably get removed in the next Minor Update (f.e. RabbitMQ 4.4). The applications should already be checked and adapted if necessary before the next update.

The following features are deprecated and will be removed in the near future:

  • global_qos: basic.qos with global=true is rejected. Use per-consumer prefetch instead.
  • transient_nonexcl_queues: Non-exclusive transient (non-durable) queues can no longer be declared. Existing transient queues will be deleted during the future upgrades of RabbitMQ.
  • queue_master_locator: The x-queue-master-locator queue argument and queue-master-locator policy key are rejected. Use x-queue-leader-locator and queue-leader-locator instead.
  • amqp_address_v1: The AMQP 1.0 address format v1 will be rejected. Use address format v2.