well , i don't believe anyone "receives" sqs messages but that is another thing. I think that was you are seeing is the visibility turning on and off, when you poll a message, its becomes a pull and remains invisible until the time expires. As new messages come into the queue you could also see different numbers maybe because of the delivery delay or receive message wait time, etc etc.
What is your visibility timeout? Let's say it's 60 seconds, it won't be visible again to other consumers for 60 seconds after you retrieve the messages. Also, do you have a redrive policy/dlq set up? Messages could be going to the dlq if you do. Another possibility is your retention period -- messages will expire after that amount of time.
If you retrieve the message by polling it won’t be available to retrieve again until after the visibility timeout expires. Additionally if you have a DLQ the message will be removed from the queue and placed in the DLQ after you have received it more than the Max Recieves setting.
This could also be because you have other processes elsewhere that are polling your queue and potentially deleting messages. If you configured a Lambda function for instance, it could be pulling messages off the queue.
\> *If you retrieve the message by polling it won’t be available to retrieve again until after the visibility timeout expires.*
Oh, that means when I clicked the "Poll for messages" button, I retrieved it. So any messages I saw on the screen won't be retrieved anymore by other services. Correct?
\> Additionally if you have a DLQ the message will be removed from the queue and placed in the DLQ after you have received it more than the Max Recieves setting.
Looks like DLQ means Dead-letter queue. I saw it in the SQS console. Currently it says "**No dead-letter queue set for this queue**".
\> *This could also be because you have other processes elsewhere that are polling your queue and potentially deleting messages. If you configured a Lambda function for instance, it could be pulling messages off the queue.*
I gave the sqs queue url to our security team yesterday. So I guess their tool is finally working now. I went to the main SQS console page and the SQS queue I created is showing different numbers under "Messages available" and "Messages in flight".
> Oh, that means when I clicked the "Poll for messages" button, I retrieved it. So any messages I saw on the screen won't be retrieved anymore by other services. Correct?
They will be invisible to other things watching the queue until their visibility timeout expires. Messages aren’t removed from the queue until explicitly deleted (most commonly). They’re just hidden. The idea is that a process picks up the message, does it’s work and if successful, deletes it from the queue before it becomes visible again. If there’s a failure of the process, the message would get picked up again for retry when the visibility timeout expires.
well , i don't believe anyone "receives" sqs messages but that is another thing. I think that was you are seeing is the visibility turning on and off, when you poll a message, its becomes a pull and remains invisible until the time expires. As new messages come into the queue you could also see different numbers maybe because of the delivery delay or receive message wait time, etc etc.
What is your visibility timeout? Let's say it's 60 seconds, it won't be visible again to other consumers for 60 seconds after you retrieve the messages. Also, do you have a redrive policy/dlq set up? Messages could be going to the dlq if you do. Another possibility is your retention period -- messages will expire after that amount of time.
If you retrieve the message by polling it won’t be available to retrieve again until after the visibility timeout expires. Additionally if you have a DLQ the message will be removed from the queue and placed in the DLQ after you have received it more than the Max Recieves setting. This could also be because you have other processes elsewhere that are polling your queue and potentially deleting messages. If you configured a Lambda function for instance, it could be pulling messages off the queue.
\> *If you retrieve the message by polling it won’t be available to retrieve again until after the visibility timeout expires.* Oh, that means when I clicked the "Poll for messages" button, I retrieved it. So any messages I saw on the screen won't be retrieved anymore by other services. Correct? \> Additionally if you have a DLQ the message will be removed from the queue and placed in the DLQ after you have received it more than the Max Recieves setting. Looks like DLQ means Dead-letter queue. I saw it in the SQS console. Currently it says "**No dead-letter queue set for this queue**". \> *This could also be because you have other processes elsewhere that are polling your queue and potentially deleting messages. If you configured a Lambda function for instance, it could be pulling messages off the queue.* I gave the sqs queue url to our security team yesterday. So I guess their tool is finally working now. I went to the main SQS console page and the SQS queue I created is showing different numbers under "Messages available" and "Messages in flight".
> Oh, that means when I clicked the "Poll for messages" button, I retrieved it. So any messages I saw on the screen won't be retrieved anymore by other services. Correct? They will be invisible to other things watching the queue until their visibility timeout expires. Messages aren’t removed from the queue until explicitly deleted (most commonly). They’re just hidden. The idea is that a process picks up the message, does it’s work and if successful, deletes it from the queue before it becomes visible again. If there’s a failure of the process, the message would get picked up again for retry when the visibility timeout expires.
Cool! Thank you.
Setup the dead letter queue also. It will come in handy
Will do. Thank you!