1

I have 2 Lambda functions that respectively sent and received some workloads via a SQS. But many messages are unexpectedly sent to DLQ. I am confident that it wasn't caused by in-code bugs because not all messages went to DLQ.

I set reservedConcurrentExecutions = 1 and maxReceiveCount = 1, does it matter? I'm thinking if I increase maxReceiveCount perhaps fewer messages will be sent to DLQ.

Anyhow, I hope somebody can walk me through the methodology behind that.

Memphis Meng
  • 1,267
  • 2
  • 13
  • 34
  • what's [visibilityTimeOut](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) for the queue? How much time the lambda function takes to process the message? Are you not deleting the message from queue once the processing is done? – Chetan Apr 21 '22 at 03:38
  • Visibility Timeout =900, it takes 3 secs at most to complete one message processing. How can we delete the messages since they are supposed to disappear after being consumed. – Memphis Meng Apr 21 '22 at 04:45
  • 1
    Amazon SQS doesn't automatically delete the message. The receiver need to delete the message from queue once the processing of message is completed. Also you might already know that when the `ReceiveCount` for a message exceeds the `maxReceiveCount` for a queue, Amazon SQS moves the message to the dead-letter-queue. Hence the messages do disappear from the main queue, but they end up in DLQ. They are not deleted from the queue automatically until `MessageRetentionPeriod` is elapsed. – Chetan Apr 21 '22 at 05:43
  • So I guess the advantage of deleting messages in a queue is not blocking others afterwards being consumed. Right? I thought a "consumption" means it's deleted somehow. – Memphis Meng Apr 21 '22 at 12:03
  • 1
    @Chetan - that is only true if the application pulls the messages off the queue. If the OP is using a Lambda event source to read the messages (which it seems they are) then the message will be deleted after successful Lambda execution. – Parsifal Apr 21 '22 at 12:18
  • @MemphisMeng - what do your logs say? Are you timing out? Do you have any uncaught exceptions that cause the Lambda to exit abnormally? Are you logging the IDs of messages that you process, and the result of processing that message? – Parsifal Apr 21 '22 at 12:20
  • @Parsifal That's what I thought at the beginning, because I initially once caught the errors that I was sure they could appear (i.e. authorization error due to frequent visits), but later I changed my method by catching all kinds of errors (`except Exception as e`), no new errors showed up. I logged both the IDs and the results of the messages. – Memphis Meng Apr 21 '22 at 15:14
  • So your logs say that you successfully processed all of the messages in a batch? And that the Lambda function did not time-out doing so? – Parsifal Apr 22 '22 at 12:46

1 Answers1

3

Increasing maxReceiveCount worked eventually. The official developer guide says:

If your function returns an error, or can't be invoked because it's at maximum concurrency, processing might succeed with additional attempts. To give messages a better chance to be processed before sending them to the dead-letter queue, set the maxReceiveCount on the source queue's redrive policy to at least 5.
Memphis Meng
  • 1,267
  • 2
  • 13
  • 34