Functioning of Anypoint MQ DLQ in Mule 3
How to configure a Queue, the DLQ, assigning a DLQ to the Parent Queue, and how the message gets routed from the Parent Queue to the DLQ after failure.
Join the DZone community and get the full member experience.Join For Free
Anypoint MQ is a cloud messaging service that allows customers to perform advanced asynchronous messaging between their applications.
The dead-letter queue is the queue that messages get sent if they can't be routed to their correct destination.
By the end of the document, you will get a clear picture of how to configure a Queue, the DLQ (Dead Letter Queues), assigning a DLQ to the Parent Queue, and how the message gets routed from the Parent Queue to the DLQ after failure.
Open Anypoint platform and select MQ in that:
Note: To access Anypoint MQ you need to buy it separately from MuleSoft.
In the MQ window, we need to first select a Region where we want to create our Queues, Select a Region that contains the Data Center near to our geographical area. And then will click the plus (+) symbol to create the Queues. Every Region has its own dedicated URL which will be used at the time of configuring the Queue in the Mule flow.
Here, we will create two Queues: one will be named demo-DLQ (DLQ) and the other one will be the demo-MQ (Parent Queue) to which the DLQ will be assigned.
The demo-DLQ will have a normal configuration.
While creating the demo-MQ, we toggle the Assign a Dead Letter Queue to On State. Once the State is On we will get a dropdown option to select Dead Letter Queue Name where we can find the name of all DLQ present and here we will select our DLQ to be assigned in the Parent Queue. Down from that, there is an option to assign the number of attempts, this option defines how many retries the parent Queue will do to process the message if there is any failure while sending the message to the destination. We will set the value to 2 attempts.
Once the Queues are created with the provided configurations, we can find them in the main window. To use the Queues in our Mule flow we also need to have Client App ID and Client Secret. To achieve this we need to select the client Apps option present at the left most corner over the Queue windows and then click the plus (+) to create credentials.
Once the credentials are created, they can be seen in the Client App window.
The configuration and creating of MQ are done. Now, we will create flow and use the MQs.
We will drop an Anypoint MQ connector as a source in our flow and configure the required details.
The Complete Demo Flow:
The Transform Message will capture the payload and transform it in a readable format. The logger will display the payload.
Transform Message Code Logger:
HTTP Requester Configuration:
Note: The requestor path is pointed to a non-existing resource on purpose so that the flow will go through an error so we can demonstrate the functionality of DLQ.
All the configuration and creation of the MQ and Flows are done. Now, we will check how it functions.
Click on the name of the MQ, a new window will open, in that we will click on the Message Sender option and add the message we want to process through the flow.
We have pushed 1 message to the Queue.
The message processed through the flow and failed at the HTTP Requester as the endpoints are not valid.
While configuring the demo-MQ (Parent Queue), we have configured the Retry attempts as 2, so upon failure, the MQ will try to process the message 2 times. And the same can be observed in the console.
Now let's check the message status in the demo-MQ (Parent Queue) and demo-DLQ (DLQ).
The Message from the demo-MQ is processed, but as the flow has an error the message is routed to DLQ.
So the message is not lost and it's saved in the DLQ.
Whenever we create any flow we also create Error Handling strategies. So let's check how the DLQ will work if the Error Handling strategies are configured.
With Exception Strategy
In the existing flow, we will add a Catch Exception Strategy and a Publish Queue config to save the message in an error-demo-MQ (Error Queue) which is a normal Queue and not a DLQ.
Error Logger: Display the Request Payload:
Anypoint MQ config for error-demo-MQ:
At present the Error Queue is empty.
Now, we will again push a message in the demo-MQ (Parent Queue) and execute the flow:
Again, the retry attempt for the demo-MQ was set to 2 but it executed only once:
Reason: This is due to the Exception Strategy. As the Exception Strategy came into the picture, unlike the first scenario, it handled the exception and did not allow the MQ to have a 2nd attempt so the reroute failed and the payload got captured in the error-demo-MQ on the1st attempt.
The error-demo-MQ will have 1 message:
Whereas the DLQ has no messages:
As the DLQ is a part of the Parent Queue so it inherits the policies and properties of the Parent Queue, whereas the Error Queue is a separate normal Queue. So, in the first scenario as there was an error in the flow the message processed two times and routed the message to DLQ.
But in the 2nd scenario, the Exception Strategy overwrites the functionality of MQ and handled the exception which didn't allow the MQ to have a 2nd Attempt.
Note: The 2nd scenario is similar to the behavior of DLQ with On Error Continuous as Error Handling in Mule 4.
Published at DZone with permission of Abhishek Bathwal. See the original article here.
Opinions expressed by DZone contributors are their own.