0

I am trying to move the message to dead letter queue in AWS if there is an exception while handling the message.

Now I am deleting the original message and sending it to DLQ explicitly. However, while doing this I am losing the message meta information like Original message-id, Total receive count, first sent time stamp etc.

Below is the code snippet for the same.

@Inject
@Named("demo-queue")
private SimpleQueueService sqsService;

@Inject
@Named("dlq")
private SimpleQueueService dlqService;

.
.
.

List<Message> messages = sqsService.receiveMessages(10, 30, 20);

messages.forEach(
        m -> dlqService.sendMessage(m.getBody(),
                attr -> {
                    new SendMessageRequest()
                        .withMessageAttributes(m.getMessageAttributes())
                        .withMessageBody(m.getBody());
                    })
            );

messages.forEach(message -> sqsService.deleteMessage(message.getReceiptHandle()));

After reaching max receive count when AWS moves the message from the original queue to DLQ it preserves all mentioned attributes. Is there any way we can achieve the same using aws-sdk?

I am using the Agorapulse library with Micronaut to send/receive messages from SQS.

Not a bug
  • 4,286
  • 2
  • 40
  • 80
  • 1
    When there's an exception, don't delete the SQS messages and copy it to the DLQ, just leave the messages in the original SQS queue and receive it again and again until AWS moved it to DLQ. – Rodel Aug 21 '19 at 05:10
  • 1
    That's exactly what I want to avoid. In case of any functional bug, I know every time the receiver will fail. So I want to move it to DLQ and remove it from the original queue to avoid unnecessary handling. Two reasons, to reduce cost and unblock the queue. – Not a bug Aug 21 '19 at 05:49
  • 1
    You can set the received count to 1 so that it will immediately moved to DLQ and increase your "Default Visibility Timeout" of the original SQS queue, set it until the next cycle run. This will lessen the cost and avoid blocking the queue. – Rodel Aug 21 '19 at 06:01
  • I still want the max receive count to be 3 and have retry enabled in case of any glitch and not a functional bug :) – Not a bug Aug 21 '19 at 06:03
  • But you're moving it just after you received the exception so receive count is not a deciding factor to move to DLQ, right? Just add operational log when you received exception for you to check if it is functional bug or not. And how about setting the "Default Visibility Timeout" to a longer time, so that SQS message will not block other messages? – Rodel Aug 21 '19 at 06:06
  • 1
    And also remember that send and delete will cost you two api requests :) – Rodel Aug 21 '19 at 06:15

0 Answers0