ApsaraMQ for RabbitMQ:FAQ

Querying with AliyunAMQPReadOnlyAccess

The AliyunAMQPReadOnlyAccess policy only grants amqp:Get* and amqp:List* permissions. To access messages in a queue, you must add the amqp:BasicGet custom permission. For more information, see ApsaraMQ for RabbitMQ custom policies reference.

{
    "Version": "1",
    "Statement": [
        {
            "Action": [
                "amqp:BasicGet"
            ],
            "Resource": [
                "acs:amqp:*:*:/instances/$instanceId/vhosts/$vhostName/queues/$queueName/messages/*"
            ],
            "Effect": "Allow"
        }
    ]
}

Message accumulation after purging a queue

The purge operation does not remove delayed messages by default.

QoS mechanism

If you experience timeouts or blocking, set the QoS or Prefetch Count to 1. This prevents the client from caching too many messages that might expire simultaneously.

Dead-letter queue message delivery

A message without a TTL value is sent to the dead-letter queue only if it is negatively acknowledged (NACK) or its retry count reaches the maximum limit.

Setting a message ID

For more information, see How to set a message ID.

Message count decrease in dead-letter queues

ApsaraMQ for RabbitMQ retains messages for a maximum of 3 days. If a message is not consumed within 3 days, it is automatically deleted from the dead-letter queue, which causes the message count to decrease. For more information, see Limits.

Message retention period

ApsaraMQ for RabbitMQ retains all messages for a maximum of 3 days, regardless of whether they have been consumed. For more information, see Limits.

RabbitMQ network segments

The network segments for ApsaraMQ for RabbitMQ instances are not fixed, so you cannot obtain this information in advance.

Automatic queue deletion issues

If a consumer has not successfully subscribed to a queue, calling channel.close does not trigger automatic deletion of the queue. The auto-delete logic takes effect only after a consumer successfully subscribes by using channel.basicConsume.

Storage fees

ApsaraMQ for RabbitMQ retains messages for 3 days. The storage fee is calculated based on the storage volume of message bodies. You cannot clear this storage space manually; it is freed only when messages expire.

Because purging does not delete messages, it does not reduce your storage space usage.

Purging a queue

Purging a queue resets the consumer offset, causing consumers to skip unconsumed messages. The operation does not delete the messages, which remain accessible.

Factors determining queue egress rate

A queue's message delivery rate depends on the message volume, the number of consumers, and their QoS settings.

Considerations for exclusive queues

When you use the Spring framework in CONNECTION mode, you must create the exchange, queue, and bindings in the console beforehand. The CONNECTION mode does not automatically declare or create these resources.

Billing for message retries

You are billed only once for the initial delivery. Subsequent re-queuing and consumption attempts do not incur additional charges.

Re-queuing occurs when a consumer fails to process a message and it is returned to a server queue. The server uses a dedicated retry queue to redeliver the message to the consumer at specific intervals.

Metric for TPS limit

The TPS limit corresponds to the Peak API Request Rate per Instance metric in Cloud Monitor.

Exceeding the connection limit

Although the connection limit is documented as an instance-level limit, it is enforced at the backend node level. As a result, the total number of connections for an instance may slightly exceed the stated limit.

The configurations of subscription instances cannot be adjusted dynamically. We recommend that you plan your resources carefully when creating an instance to avoid exceeding resource limits and causing business disruptions.

Message accumulation with balanced rates

Even if the production and consumption rates are balanced, delays in acknowledging (ACK) some messages can cause monitoring tools to report a temporary message accumulation at a specific sampling time. The accumulation level usually returns to normal in the next sampling cycle.

Sudden drop in pod consumption rate

We recommend checking the performance of the pod. High CPU utilization can prevent the client from sending ACKs promptly. If the server does not receive an ACK, it cannot push new messages and must wait for a timeout before retrying. This leads to a drop in the consumption rate.

For example, if QoS is set to 1, the consumer can have only one unacknowledged message at a time. The server must wait for the consumer to process the message and send an ACK before it can push the next message. If no ACK is received, the server must wait for a timeout before retrying.

Using the default master key

Yes.

Error: "The channelMax limit is reached"

The server limits the number of channels per connection, not the total number of channels across all connections.

This error is logged by the SDK whenever the createChannel method returns null.

After you upgrade an instance, you must restart your clients. Otherwise, existing connections will continue to use the pre-upgrade channel limit, causing the error to persist.

For example, if an instance is purchased with a Channel Max of 100, the client and server negotiate this limit when a connection is established. If you later upgrade the instance to support 2,000 or 2,500 channels, connections established before the upgrade are still bound by the original 100-channel limit and will continue to trigger the error.

Channel parameter negotiation process

Impact of upgrading TPS

No. Upgrading the TPS limit in the console does not interrupt or disconnect existing connections.

New connections causing channel shutdowns

Normally, no. However, insufficient client resources, such as network bandwidth, memory, or JVM capacity, can cause other connections or channels to be interrupted. We recommend examining the client's resource usage for resource contention or shortages that might be causing these interruptions.

Disappearing queue consumers

We recommend first checking the client's application logic and resource status at the time of the incident. Look for issues like suspended processes or resource shortages that could have interrupted the application. If the client is functioning correctly, then verify whether the server is delivering messages as expected.

Queue purge not taking effect

Purging a queue does not clear unacknowledged (unacked) messages. These are messages that have been delivered to a client but have not yet been acknowledged. The unacked message count is updated automatically after the messages expire.

Calculating TPS from client logs

Use the following SQL query:

 * and amqp-cn-xxx and Action : SendMessage | select InstanceId as instance_id, VHost as virtual_host, Queue as queue, microtime / 1000 / 1000 as time_second, count(*) as send_qps group by instance_id, virtual_host, queue, time_second order by time_second, send_qps limit 10000000

Sample result:

Empty logs after changing the Logstore

In the new Logstore, click Enable Indexing. Wait for about one minute, and then refresh the page to view the logs.

Procedure:

1) Click Enable Indexing.

2) Click OK.

Causes of RabbitMQ disconnections

If a client sends a low number of valid ACKs, the server repeatedly redelivers messages because it does not receive acknowledgments. This can lead to a persistent message accumulation.

This message accumulation on the client side can prevent the connection from sending heartbeat packets. This eventually triggers a Connection ALL_IDLE error and a disconnection. You should first investigate why the client is failing to send valid ACKs.

TTL settings

The maximum TTL is 3 days; any setting greater than 3 days is ineffective. If the TTL is ineffective, expired messages are not moved to the dead-letter queue and may cause other unexpected behavior.

1) If no TTL is set, all messages in the queue are normal messages. The readyMessage metric in monitoring reflects the actual number of accumulated messages.

2) If a TTL is set, the readyMessage metric represents the number of live messages:

a) If the TTL is working correctly, the number of live messages is dynamically calculated based on the TTL. The readyMessage metric accurately reflects this number.

b) If the TTL is set but is not effective, the number of live messages is always 0. The readyMessage metric also shows 0 and does not reflect the actual message accumulation.

Error: "java.lang.IllegalArgumentException: Content headers exceeded max frame size: 40209 > 32768"

This error indicates that the message header has exceeded the frame size limit. The default limit for a message header is 32 KB and cannot be changed on the server.

To prevent this error, move large data from the message header to the message body.

Finding messages after a queue purge

The message search function queries log data, not the live queue. Because logs are retained longer, you can find records of messages even after they are purged from the queue.

Unbinding subscription error

Cause:

An exclusive queue is visible only to the connection that first declared it. Therefore, it can only be deleted by that specific connection and not from the console.

For more information, see Exclusive queues.

Solution:

1) If you no longer need the exclusive queue, disconnect the corresponding connection. The queue and its bindings will be automatically deleted.

2) If you cannot find the ID of the connection that created the queue, delete the exclusive queue by restarting the client.

Error: "VPC flow is not allowed to login in"

Cause:

The server detects that the credentials used are not static credentials generated from the console. It misinterprets the request as open-source authentication traffic and rejects the connection.

Solution:

After confirming connectivity from your VPC, ensure that you are using the static credentials generated in the console. If you are unsure, we recommend regenerating the credentials.

Instance creation takes more than 30 minutes

Troubleshooting steps:

• Verify that the VPC specified during instance creation exists, belongs to your account (UID), and is in the Available state.

• Verify that the vSwitch specified during instance creation meets the requirements. You can refer to the VswitchIds parameter of the CreateInstance API.

Cause:

This issue typically occurs when the VPC or vSwitch configuration changes during the instance creation process. For example, if the VPC is deleted after the initial request validation passes, the asynchronous instance creation fails.

Solution:

If the creation parameters changed during the process (for example, the VPC or vSwitch was deleted), release the ApsaraMQ for RabbitMQ instance and create a new one.

Cross-region private network access

The standard solution for cross-region private network access is to use a combination of PrivateLink and Cloud Enterprise Network (CEN).

Note that this solution incurs PrivateLink fees. For more information, see PrivateLink endpoints.

Error creating PrivateLink endpoint: VPC parameter

Cause:

The VPC ID does not exist, or the VPC is not in the Available state.

Solution:

Verify that the selected Virtual Private Cloud (VPC) exists and is in the "Available" state. You can check the VPC's status in the VPC console.

Error creating PrivateLink endpoint: VSwitch parameter

Cause:

The selected vSwitch does not meet one or more of the following conditions:

• You must select vSwitches from at least two different zones (this does not apply to some single-zone regions).

• The vSwitch must belong to the selected VPC.

• The vSwitch must be in the Available state.

• The vSwitch must have at least 20 available IP addresses.

• The zone where the vSwitch resides must support NLB creation.

Solution:

• Check the number of vSwitches: For single-zone regions (such as Nanjing, Fuzhou, Wuhan-Local, Southeast Asia 6, Southeast Asia 7, NE 2, and MEA 1), select at least one vSwitch. For other regions, select vSwitches from at least two different zones.

• Ensure that the vSwitch belongs to the selected VPC and is in the Available state.

• Ensure that the vSwitch has at least 20 available IP addresses.

• Ensure that the zone where the vSwitch resides supports NLB creation.

Error creating PrivateLink endpoint: SecurityGroup parameter

Cause:

The selected security group does not meet one or more of the following conditions:

• The security group must have an inbound rule that allows TCP traffic on destination ports 5672 and 5671.

• Managed security groups are not supported.

• The security group must belong to the selected VPC.

• The number of security groups must not exceed your account's quota.

Solution:

• Ensure the security group has an inbound rule that allows TCP traffic on destination ports 5672 and 5671.

• Ensure that you have not selected a managed security group.

• Ensure that the security group belongs to the selected VPC.

Error: PrivateLink service not activated

Cause:

The PrivateLink service is not activated for your account.

Solution:

Activate the PrivateLink service, and then try to create the PrivateLink endpoint again. For more information, see What is PrivateLink?.

What causes IOException or connection error on the client?

The following can cause IOException or connection error: