FAQ: Anypoint MQ

Anypoint MQ requires a separate Enterprise subscription and is not included in the Anypoint Platform trial version. Contact your Account Team for more information. If you don’t have an Enterprise subscription, you can use Apache Active MQ or Rabbit MQ.

After adding an Enterprise subscription, wait one hour for Anypoint MQ to become available.

Anypoint MQ standard and FIFO queues are available in these regions:

After you obtain an Enterprise subscription and contacted your Account Team to activate Anypoint MQ, you can use Anypoint Platform to create a queue or message exchange, and send messages to it. For more information, see the Configuring and Using Queues and Sending Messages to Multiple Queues Using Message Exchanges.

Anypoint MQ uses in-flight HTTPS encryption with Transport Layer Security (TLS) 1.2 protocol to transport messages and doesn’t support the deprecated TLS versions 1.0 and 1.1.

If you configure Anypoint MQ queues for encryption at rest, the payloads are encrypted with the AES-256 GCM algorithm on the server side.

If your app requires an additional layer of encryption security, then you can encrypt the payloads yourself before publishing messages to Anypoint MQ. You must manage your encryption keys for both the message publishers and the consumers.

When you have a queue encrypted, the messages are stored encrypted but they are decrypted when they are read. Encryption and decryption are automatic and transparent to the final user. There’s no option to disable the automatic decryption. If you need to encrypt the message so that the payload remains encrypted, manually encrypt the content.

The body of an Anypoint MQ message is sent as a string as part of a JSON message, thus any content that needs to be published should be serializable in a string format from which you can later deserialize. One way to do this is to serialize the Java object to its JSON representation using DataWeave, which can be serialized and deserialized from a string. Sending Java objects that don’t have a proper string serialization causes the message to be unreadable on the receiving end.

No, queues and message exchanges are unique to the region in which they were created and cannot share messages or queues between regions. Developers can manually create custom programs that load balance between regions, but Anypoint MQ itself does not provide multi-region support.

The queues in each region are separate from those in other regions. You can name queues the same in each region, but queues can’t share messages across regions.

Anypoint MQ doesn’t support propagating correlationId from a publisher to a subscriber in the same way that APIs propagate it from one layer to another.

To pass an ID between publisher and subscriber, add a user property to send with the message. For information, see Send a Message to a Queue.

For more information about correlation IDs, see Total traceability with correlation IDs.

In Anypoint Platform > MQ > Message Browser, you can fetch up to 50 messages from a standard (non-FIFO) queue.

For a FIFO queue, the Message Browser UI limits the number of messages you can retrieve to 10. The FIFO restriction exists because the FIFO queues are limited to 10 in-flight messages per message group. For more information about in-flight messages, see How many in-flight messages can I have per queue?

Anypoint MQ is a highly distributed messaging system, so the results of an API call to receive messages are not guaranteed to be entirely representative of what is fully in the queue. Anypoint MQ operates in a best-effort case. For example, if there are 5 messages in a queue, the system returns anywhere from 0-5 messages in a single API call depending on what distributed subsystems are accessed by that request. Subsequent API calls retrieve more messages and if you keep making API requests to receive messages, then you get all of them. Normally in high throughput cases, repeated API calls happen extremely fast. The Anypoint MQ connector, for example, continuously polls the Anypoint MQ backend for new messages and from the user perspective, the messages are processed nearly instantly even though many API calls were used.

Standard queues attempt to preserve the order of messages, but strict order is not guaranteed. Because standard queues are designed to be scalable and distributed, they can’t guarantee that messages are received in the same order that they are sent. If message order is important, use a FIFO queue or set Anypoint MQ Connector to the Consume operation.

Anypoint MQ supports payloads up to 10 MB.

If the payload contains any format except text (such as CSV, HTML, JSON, and XML), Anypoint MQ converts it to a string before sending, which increases the payload size. This conversion might result in the payload exceeding the maximum payload size of 10 MB and causing a Payload too large error.

If a larger size is required, you can split the payload into multiple messages, or implement a claim check style service in which you store the payload in a file system or blob storage, and then put a pointer to the payload in the message so it can be downloaded later. However, you must manage access control to the blob storage for both the sender and receiver. You also need to consider that messages can be received unordered unless you use a FIFO queue.

The Message Browser page displays the payload only if the payload size is smaller than 1 MB. If the payload size is 1 MB or larger, the Message Browser page displays an error. In this case, you can use the Anypoint MQ Broker API to display the message payload. See Retrieve a Message.

That is, how do we ensure message exchanges or queues created in one environment are not confused or connected to message exchanges or queues created in a different environment if they have the same name?

You can have the same object name for queues and exchanges in different environments, but the client app ID and client secret values must be unique. You can’t access a production queue from a development environment if they don’t have the corresponding client app IDs.

You can use Anypoint Platform > Access Management > Business Groups or Environments. The queues and message exchanges created in a business group or environment are only visible to those with access to the business group or environment.

You can publish a message from an on-premises system to Anypoint MQ and have another on-premises subscriber pull messages from Anypoint MQ. Currently, Anypoint MQ cannot be deployed on-premises. If you need a messaging source on-premises, you can use Apache Active MQ instead.

Within each region, Anypoint MQ services deploy to multiple availability zones (AZs) to provide high availability (HA). If service in one availability zone goes down, the Anypoint MQ service operates normally in that region. If all availability zones go down in a region, the Anypoint MQ service is unavailable in that region until at least one of the availability zones comes back up. Because the storage solution for Anypoint MQ is durable, messages that were already in the Anypoint MQ system before service was interrupted are retained.

Anypoint MQ also provides cross-region failover for standard queues. When you enable failover for a queue, Anypoint MQ automatically creates a fallback queue in a fallback region. If a Mule app can’t reach an Anypoint MQ server in a region, it switches to the fallback queue to publish and consume messages.

You cannot use reconnection strategies with the Anypoint MQ connector because it does not use a connection-based protocol. Instead, it uses REST behind the scenes.

On the inbound side, you can easily mimic a retry strategy using a max redelivery attribute set to your maximum number of retries and an exception strategy to move to a dead-letter queue (DLQ) when the limit is reached.

On the outbound side, you should use the same triggering mechanism. Otherwise, you can use the until-successful element with this connector.

You should also configure the HTTP connector so that Global Element Properties > Set Max Redelivery is set to the value of -1.

There is no built-in functionality to replay messages from a DLQ. You must implement a special flow or app to consume those messages and forward them back to the original queue for reprocessing.

The network that Anypoint MQ runs on provides high availability replications across its many datacenters.

If a server fails and failover occurs, messages continue to be processed by other servers on the network in which Anypoint MQ runs. Standard Anypoint MQ queues do not guarantee only-once message delivery. Only FIFO queues support only-once message delivery. The high availability network deduplicates messages for FIFO queues automatically.

Yes, Anypoint MQ guarantees "at least once" delivery of messages to the destination.

Every API call to Anypoint MQ counts as one API request. Counting each call as a request includes sending, receiving, and acknowledging messages as well as all operations on queues and exchanges.

Up to 10 messages can be retrieved from a single API call, which only bills as one request. Even if the request to retrieve messages does not return a message, for example, if the queue is empty, it still bills as a single API request.

Maximum transactions per second (TPS):

There is no maximum number of queues or exchanges.

Anypoint MQ supports up to 120,000 in-flight messages per standard (non-FIFO) queue.

FIFO queues allow up to 10 in-flight messages per message group due to the extra processing required. Anypoint MQ doesn’t limit the number of message groups in a FIFO queue.

A single queue can contain an unlimited number of messages. The maximum duration for any message, either in-flight or not, is two weeks, after which Anypoint MQ deletes the message.

The connector does not store the message for resending it. The connector retries 5 times after which the message is discarded and it becomes the responsibility of the app to decide what to do with a message.

Retries for sending messages to Anypoint MQ broker are always synchronous. By contrast, the client mode specifies how to establish the connection to the backend and does not govern message-sending retries.

Retries are arbitrary. The maxRedelivery parameter indicates how many times the messages were delivered but not processed (either NACK or TimeOut).

Using the Anypoint MQ Broker API, you can batch-upload and batch-retrieve messages from a standard or FIFO queue. For information, see Anypoint MQ Broker API.

You can upload or retrieve a maximum of 10 messages (default) in a single call.

For batch-retrieve operations, use the batchSize query parameter to specify the number of messages to retrieve. Anypoint MQ Broker API doesn’t guarantee the number of messages retrieved in a single call. See Why do I receive fewer messages than my batch size when retrieving messages with the Anypoint MQ REST API?.

If you have non-Mule applications, you can use the Anypoint MQ REST APIs to send and receive messages.

Anypoint MQ is horizontally scalable and supports higher throughputs as needed.

Anypoint MQ provides long polling. You can do a REST request and ask the server to keep the TCP socket open for up to 20 seconds to fulfill your request if there are not enough messages.

You can use FIFO queues to process messages in order.

If you don’t want to use FIFO queues, you can process messages one at a time by setting Anypoint MQ Connector to the consume operation. This operation retrieves a message from the queue or receives null if a message is not available.

Then, depending on your Mule version:

Mule 4

Add the maxConcurrency="1" attribute to the flow element.

Specify this attribute to set the number of simultaneous invocations that a component can receive at any given time to 1.

Mule 4 Example:

Mule 3

Mule 3 Example:

More than one in-flight message can occur if the processing time between anypoint-mq:consume and anypoint-mq:ack is higher than the value of the Default Acknowledgement Timeout setting for the queue.

Anypoint MQ provides direct access to the message ID and payload. You can see the message headers using the Chrome browser and its Network Inspector feature.

The only officially supported connectors and transports for shared resources are HTTP/HTTPS, VM, JMS, JMS Caching Connection Factory, Database, WMQ, JBoss Transaction Manager, and Bitronix Transaction Manager.

You can use a curl command with the Anypoint MQ Admin API in a for loop to create the number of queues and message exchanges you need. See Anypoint MQ REST APIs.

Yes, the usage charges apply to all environments.

If your usage exceeds your license limit, Anypoint MQ continues to work. MuleSoft notifies your account administrator and team with any billing-related information.

When using Anypoint MQ as a message processor with prefetch, use only a global prefetch configuration.

For example, the following local prefetch does not work:

Use a global prefetch instead:

To delete a queue, see Delete a Queue.

To delete a message exchange, see Delete a Message Exchange.