FAQ: Anypoint MQ
If you choose to encrypt messages, Anypoint MQ provides password-based encryption using PBE with MD5 and Triple DES, and with a 168-bit key.
If the blue create button doesn’t list FIFO Queue:
Ensure you have an Anypoint MQ FIFO entitlement. Check with your MuleSoft representative.
Ensure that your region setting is US-West:
Anypoint MQ supports up to 120,000 in flight messages per each non-FIFO queue. FIFO queues permit up to 20,000 in flight messages per FIFO queue due to the extra processing required for FIFO queues. An in flight message is a message received by a queue, but not deleted, that is, a message awaiting ACK or NACK, or a message with an expired Default Lock TTL (time-to-live) setting. A single queue can contain an unlimited number of messages; however the number of in flight messages is limited. The maximum duration for any message, either in flight or not is 2 weeks, after which Anypoint MQ deletes the message.
Yes the REST API supports the
batchSize query parameter which lets you retrieve up to 10 messages in a single call. If you need to fetch more than 10 messages in a single call, you can configure the Prefetch Config parameter in the Anypoint MQ Connector as described in Studio Prefetch Tab.
You can publish a message from an on-premises system to Anypoint MQ and have another on-premises subscriber pull messages off of Anypoint MQ. Currently Anypoint MQ cannot be deployed on-premises. If you need a messaging source on-premises, you can use MuleSoft’s Active MQ instead.
If you have non-Mule applications, you can use our MQ REST API to send and receive messages.
Anypoint MQ is horizontally scalable and we can support 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.
To process messages one by one, set the Anypoint MQ connector to the consume operation, which retrieves a message from the queue, or receives null if a message is not available. In addition, use a synchronous flow with a poll scope to fire the process regularly. More than one in-flight message can occur if the process time between
anypoint-mq:ack is not lower than the Default Lock TTL for the queue, and if you don’t create exception options and NACK the message accordingly.
1 2 3 4 5 6 7 8 9 <flow name="testanypointmq1by1Flow2" processingstrategy="synchronous"> <poll doc:name="Poll"> <logger doc:name="Logger" level="INFO" message="Pooling fired"></logger> </poll> <anypoint-mq:consume config-ref="Anypoint_MQ_Configuration" destination="queuename" doc:name="Anypoint MQ"/> <logger doc:name="Logger" level="INFO" message="Processing message received. #[payload]"/> <anypoint-mq:ack config-ref="Anypoint_MQ_Configuration" doc:name="Anypoint MQ"/> <logger doc:name="Logger" level="INFO" message="Message processed."/> </flow>
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.
There are multiple data centers in a region which again have multiple availability zones. One availability zone going down does not affect Anypoint MQ services. If the whole region goes down, only a service in that region can be affected.
Anypoint MQ provides persistent data storage across multiple data centers in a region, ensuring that it can handle data center outages and provide full disaster recovery in case of an availability zone going down.
The Anypoint MQ connector does not exactly use a connection-based protocol, but uses REST behind the scenes, and therefore, you cannot use reconnection strategies with this connector.
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 DLQ when the limit is hit.
On the outbound side, stick to 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
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 on other servers in the network on which Anypoint MQ runs. Normal 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.
To delete a queue:
Click the right side of the queue entry in the Destinations table:
Click the trash can symbol in the upper right.
In the Delete Queue menu, click the checkbox:
Click Delete Queue.
Note: The time it takes to delete or purge a queue is approximately one minute. During this time, the status of the affected queue may not be updated.
To delete a message exchange:
Click the right side of the message exchange entry in the Destinations table:
Click the trash can symbol in the upper right.
In the Delete Exchange menu, click the checkbox:
Click Delete Exchange.