The host that my SQS app runs on recently experienced some external DNS resolution issues. This meant that suddenly, I couldn't hit the SQS API endpoints. As a part of figuring out what was going on, I logged into the AWS console only to find the messages count slowly declining.
If the messages could not have been consumed by my app, how could the number of messages in the queue be declining?
Amazon SQS automatically deletes messages that have been in a queue for more than the maximum message retention period.
By default, the message retention period is 4 days. However, you can set the message retention period to any value from 60 seconds to 1,209,600 seconds (14 days) in the AWS console.
Link
Related
I have a lambda that is triggered by an SQS but I want to disable the event trigger in the lower environments.
If there are other parts that publishes to that SQS, what would happens to the the message? There is no DLQ on the SQS. Will the message disappear after the MessageRetentionPeriod is up?
Per the SQS FAQ:
Q: How long can I keep my messages in Amazon SQS message queues?
A: You can configure the Amazon SQS message retention period to a value from 1 minute to 14 days. The default is 4 days. Once the message retention quota is reached, your messages are
automatically deleted.
The word 'quota' is a bad choice, imo, but it means the message retention period.
Note: if a message happens to have been moved from a regular SQS queue to its associated Dead Letter Queue then the retention period is considered to start when the message first arrived on the underlying SQS queue, not when it was transferred to the DLQ.
Say that I have a SNS which I am self throttling using the attribute maxReceivesPerSecond. Let's say we have a very high production rate, but due to the throttling, the consumption is very slow. This can lead to some messages being in the SNS for a long time.
I saw this SO answer, where it's mentioned that such messages will be deleted after 1 hour. But the quote doesn't exist in the documentation anymore.
So what is the current policy of deletion of un-delivered messages in a SNS now?
Amazon SNS now allows you to set a TTL (Time to Live) value of up to two weeks for each message. Messages that remain undelivered for the given period of time (expressed as a number of seconds since the message was published) will expire and will not be delivered.
You should refer to this link for more details:
https://aws.amazon.com/blogs/aws/sns-ttl-control/
I have a simple lambda app that is not in production right now, only being used for testing and debugging. The function sends a message to SQS to perform CRUD operations on an external application. I've set this function to be invoked by SQS when it receives a message, so the same function is sending and receiving.
I've just received an email saying I've used over 85% of my free tier SQS requests quota, or over 850,000 requests in just the past 2 weeks. I'm certain these requests are not messages being sent to queue, or received. The number of sends/receives has to be under 1000 for how often I've used this app. I've also verified using SQS monitoring that there are no messages stuck in queue. And the number of sent messages is more or less what I expected, a low number.
Like I said this app is only being used by myself for testing, a few days per week. Where does the 850,000+ requests come from?
Amazon SQS is charged at $0.40 per million API calls. Calls include send, receive and delete, so it is possible that a message might use 3+ API calls.
From AWS Lambda Adds Amazon Simple Queue Service to Supported Event Sources | AWS News Blog:
There are no additional charges for this feature, but because the Lambda service is continuously long-polling the SQS queue the account will be charged for those API calls at the standard SQS pricing rates.
Long-polling takes 20 seconds, which makes 4320 polls per day. This equates to 60,480 over two weeks or 129,600 per month. Admittedly, it would be more if messages are flowing, since long polling exits whenever there are messages.
So, either the queue is being used a lot (and you are getting excellent value for your $0.40) or you have something else generating lots of SQS API calls.
If you use the same function for sending to SQS and receive from SQS, it means that:
Lambda send message to SQS -> SQS receive the message -> SQS trigger Lambda -> Lambda send message to SQS
And... It's an infinite loop :)
I have configured a SNS topic with 2 subscriptions: Email and a Lambda function. Everything worked fine until yesterday (04/04/2016). When I publish a message to the SNS Topic the Email notification arrives fast. But the invocation of the Lambda function happens eventually but hours later.
Nothing has changed about the function, IAM, etc. This is happening in the Ireland region and I don't see any errors in CloudWatch logs and metrics.
Any idea why this happens and how I can prevent this and/or monitor this?
Could be throttling. Your account is only allowed to run a certain number of lambdas concurrently (I think 1000 is the default limit now). If SNS triggers a lambda and it gets rejected because you have 1000 lambdas running, SNS will wait and retry and then wait longer and retry.
When we have bursts of activity we have seen our SNS triggers delayed by 30-90 minutes. Supposedly it will keep trying for up to 6 hours.
You can check this in the console by going to the main dashboard for the lambda service. It shows you a graph of how many lambdas have recently been throttled.
How does the Amazon SQS's DLQ work when it comes to old messages?
Do messages older than 14days() get moved to DLQ instead of being deleted ?
I dont see any documentation relating to how older messages are handled.
From the documentation it looks like just the errored messages are moved to DLQ, is my assumption right ?
Your understanding is correct; Messages that are older than the retention period you have set (max of 14 days), will be deleted, not moved to the DLQ.
SQS automatically deletes messages that have been in a queue for more
than maximum message retention period. The default message retention
period is 4 days. However, you can set the message retention period to
a value from 60 seconds to 1209600 seconds (14 days) with
SetQueueAttributes.
http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/MessageLifecycle.html
All the messages that are not processed/consumed will gets pushed to DLQ.
Amazon SQS supports dead-letter queues (DLQ), which other queues (source queues) can target for messages that can't be processed (consumed) successfully.
Reference - https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html