DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Newsletter
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Optimizing Java Applications: Parallel Processing and Result Aggregation Techniques
  • A Better Web3 Experience: Account Abstraction From Flow (Part 1)
  • Error Handling Inside Kumologica Subflow
  • Techniques You Should Know as a Kafka Streams Developer

Trending

  • Threat Modeling Context-Aware AI: A STRIDE Walkthrough
  • SSRF Prevention in C#: Securing File Imports From User-Supplied URLs
  • Beyond @Transactional: Solving the Dual-Write Problem in Distributed Microservices
  • Java 8 Optional - Avoid Null and NullPointerException Altogether - and Keep It Pretty

Draft This article hasn't been published, so readers can't see it.

In moderation This article is waiting for review, so readers can't see it yet.

Deleted This article has been deleted, so readers can't see it.

  1. DZone
  2. Data Engineering
  3. Databases
  4. Step-by-Step Guide to Use Anypoint MQ: Part 2

Step-by-Step Guide to Use Anypoint MQ: Part 2

Learn how to implement a DLQ with your queue, look into the message that was not delivered, and take the necessary actions to reprocess it.

By 
Anand Joshi
·
Dec. 30, 20 · Tutorial
Post on X (opens in a new tab) Share on LinkedIn (opens in a new tab)
9.5K Views

Join the DZone community Save articles, join the discussion, and download Refcards and Trend Reports with a free account.

Join for free Already a member? Log in

This blog is the second part of the Step-by-Step Guide to Use Anypoint MQ series. You can find Part 1 here. In this blog, we will learn about dead letter queue (DLQ) and how to use it in the Mule API.

Dead Letter Queue (DLQ)

A dead letter queue is used to keep/store the undelivered messages that are not routed to the destination. DLQ, sometimes referred to as an undelivered message queue, is a holding queue for messages that cannot be delivered to their destination queues.

There might be cases where we want to make sure that in case of any failure, our message won’t get lost. In such scenarios, dead letter queue (DLQ) can be used. A dead letter queue is associated with one or more queues, which are called the parent queue.

There are a few more things to remember before creating a DLQ. The DLF and parent queue both need to be:

  1. Same type of queue (standard or FIFO)
  2. Created in the same geographical region
  3. Created in the same environment and owned by the same Anypoint Platform account

The process of creating of a dead letter queue is same as normal queue. We create a DLQ and assign it to another queue.

Our queue, named DLQ-test-queue, is created.

Now, we will assign it as a dead letter queue to another queue named test-queue.

Create a queue named test-queue and click Assign a Dead Letter Queue.

A drop-down field for the DLQ will appear. There, we can see the queue DLQ-test-queue; select that queue. The field Reroute After this is used to tell how many times MQ attempts to deliver the message in the queue before rerouting the message to the DLQ. Set this value as 2. See the below image: 

We can see both the queues on the Anypoint MQ console.

 

Let’s check whether the undelivered message re-routes to DLQ.

For this, we will create two flows — the first for publishing the message into the queue and second for subscribing the message from the queue. In the subscriber flow, we will add a raise error component to get a custom error (DLQ:DEMO_ERROR) so that the flow will give an error just after receiving the message from the queue.

Send the below message from Postman:

Let’s have a look on the logs. We can see that the message is published to Anypoint MQ by anypointmq-demoFlow. Upon completion of this flow, our subscriber flow (anypointmq-demo-SubscribeFlow) is executed and we can see that it failed two times before sending the message to the DLQ. This is because we set the value as 2 for the Reroute After field in the queue. 

Let’s see if the message is delivered to DLQ. 

This is how we can implement a DLQ with our queue, look into the message that was not delivered (due to a processing error, server error, or any other error), and take the necessary actions accordingly to reprocess it.

Flow (web browser) Blog Console (video game CLI) Holding (law) Processing API

Opinions expressed by DZone contributors are their own.

Related

  • Optimizing Java Applications: Parallel Processing and Result Aggregation Techniques
  • A Better Web3 Experience: Account Abstraction From Flow (Part 1)
  • Error Handling Inside Kumologica Subflow
  • Techniques You Should Know as a Kafka Streams Developer

Partner Resources

×

Comments

Loading comments

The comments didn't load

Please try again in a moment.

Likes

Loading

The next likes didn't load. Please try again.

The likes didn't load

Please try again in a moment.

See who liked this

Log in or join DZone for free to see who liked this article.

Log in Join for free
  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook