Recent AWS Customer Success Stories & Videos

More AWS Customer Success Stories...

« Amazon EC2 Instance Usage and Reserved Instance Utilization Reports | Main | Two New Locations for Amazon Simple Email Service »


Feed You can follow this conversation by subscribing to the comment feed for this post.

Jon Gallagher

This is wonderful, particularly for those of us porting legacy software to AWS. If you have a wrapper around a program where the wrapper is receiving jobs from SQS then feeding the information to the legacy program (think shell script invoking a program's command line) you may not be able to peer into the program to see if there is a problem with mis-formatted data, the volume of the data, etc..

Before this all you had was the ability to time out and restore the message back to the queue, then query messages that had gone through too many times. Now the presence of a Dead Letter can tell us that there is a problem with queue processing, even when the program receiving its input from the queue is completely unaware of SQS.

Good Job SQS folks!

Oleg Kozlov

The issue of stuck messages could be solved by checking value of ApproximateReceiveCount attribute delivered with the message. It shows how many times the message was delivered, and it it pretty accurate in my testing. The attribute is not sent by default you have to request explicitly when making ReceiveMessage call.

Then on the client you can check the value and implement special handling for message re-delivered over certain number of times. DLQ is nice though since it allows you to achieve the same via configuration.

Juan Carlos

Oleg, what would happen upon the event of exceeding the attempts??

I guess what you are suggesting is:

1-Delete the message from the current queue
2-Add the same message to a different queue


1-Add the same message to a different queue
2-Delete the message from the current queue

What would happen if any of both cases, the second operation fails due to a network issue??

I guess the benefit of this new functionality is that both actions get performed under the hood and therefore we can rely on the atomicity of the operation.

Could you please give more implementation details about this??


The most important part of this document is that the message will be "moved" to dead letter queue. I was confused if I had to actually delete the dead letter or DLQ will handle it. I could only find that information in this document. At all other places you have mentioned, the dead letter will be "sent" to a separate queue, which is a natural source of confusion. Please update the other docs like to reflect the fact the message will be actually moved. Thanks.

The comments to this entry are closed.

Featured Events

The AWS Report

Brought to You By

Jeff Barr (@jeffbarr):

Jinesh Varia (@jinman):

Email Subscription

Enter your email address:

Delivered by FeedBurner

April 2014

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30