I've created an AWS SQS, and I'm just testing through the console by sending some messages. I was expecting to see the messages that I've sent listed under the "Received messages" title. But, to my surprise, approximately only one of every ten messages that I send seems to be received.
I test this, as shown in the screenshot, by clicking on "Poll for Messages" and then on "Send a message".
I'm bewildered by the fact that sometimes a message is actually received and displayed.
Wouldn't the expected behavior be to receive every single message I send?
Any idea on what's going on, please?
Have you checked message deduplication is active? There might be some deduplication by message data itself.
Or another possible reason might be some other consumer gets the message before your poll.
Related
Does the deletion AWS SQS message (https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteMessage.html) remove/acknowledge all messages that was earlier fetched by any of consumer?
I'm asking because I would like to make sure delete operation is not working in similar way to acknowledge described in (https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/getting-started.html)
In this mode, when a message is acknowledged, all messages received before this message are implicitly acknowledged as well. For example, if 10 messages are received, and only the 10th message is acknowledged (in the order the messages are received), then all of the previous nine messages are also acknowledged.
The acknowledgements are a feature of JMS. When you work with SQS directly, there are no acknowledgements sent to the producer of the messages.
If you require such acknowledgements you would have to develop request-response system yourself, or use pre-existing solutions for that (such as with JMS).
If I send a message to my own phone, it gets received properly. If I send it to my wife or son's phone, the message does not get received. Despite this, the SNS dashboard says that the messages were properly sent. I hope I'm missing something, but at this point, I don't feel like I can use SNS for customer facing apps if all the feedback I get says it worked fine, but I can't guarantee that the users actually receive a text. This is the first time I've used SNS in this way. Is this expected behavior or am I maybe missing something?
I'm trying send individual SQS messages with a delay. Using https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-send-message-with-timer.html to test message delays, I'm not seeing any delay.
If I set a delay on the queue, that delay is honoured, however not for individual messages. I'm doing the following (all from the AWS console):
Open the SQS console and right click on my test queue - verify that there the delay value for the queue is 0.
Right click on the test queue and click 'Send a Message'
Add a message body
Set 'Delay delivery of this message by' to 30 seconds
Click Send Message.
Receive a confirmation stating 'Your message has been sent and will be ready to be received in 30 seconds.'
However when I check CloudWatch I can see that the message was delivered almost immediately. I'm I misunderstanding something, or have I missed something in the configuration?
My testing shows that messages sent to an SQS queue which a Lambda function is using as a trigger will immediately trigger the Lambda function, even if a Delay setting is provided.
See: amazon sqs - How do I return a message back to SQS from lambda trigger - Stack Overflow
When a message is sent using sendMessage() function with a MessageDeduplicationId to prevent duplicates.
However, the sendMessage function always returns true. In other words, the sendMessage function always returns a value that says message successfully sent to SQS, however the message actually is not available.
I change a field 'sent_to_sqs' in the DB based on the sendMessage() return value.
Can anybody help me?
The design assumption is that if you send a message with the same deduplication-id, then that is the exact same message you already sent (otherwise, it should not have the same deduplication-id), so SQS pretends to accept it again, on the assumption that something must have gone wrong on your side, preventing you from realizing that the message was already submitted the first time.
“the sendMessage function always returns a value that says message successfully sent to SQS”
Yes, because it already was, earlier.
SQS doesn't verify that the message is actually a duplicate -- it assumes that it is, because you've claimed it must be by submitting the same deduplication-id within the 5 minute window. If the message has already been handled, then it will not be available on the queue, by design.
Message Deduplication ID
The token used for deduplication of sent messages. If a message with a particular message deduplication ID is sent successfully, any messages sent with the same message deduplication ID are accepted successfully but aren't delivered during the 5-minute deduplication interval.
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html#FIFO-queues-understanding-logic
While using AWS SQS, does "SentTimestamp" attribute of a message change after it is received from the queue, but not deleted and returned back to the queue after the visibility timeout expired?
No, and that behavior would be undesirable because SentTimestamp specifically describes when the message was first sent to the queue.
This documentation that describes the visibility timeout offers some insight:
Immediately after the component receives the message, the message is
still in the queue. However, you don't want other components in the
system receiving and processing the message again. Therefore, Amazon
SQS blocks them with a visibility timeout, which is a period of time
during which Amazon SQS prevents other consuming components from
receiving and processing that message.
The important takeaway here is that the message never really leaves the queue, it is simply hidden from other clients that are receiving messages. So message contents like the MessageID and SentTimeout won't change. On the other hand, things related to receiving the message like RecieptHandle and Receive Count do change each time the message is received.
You can self-verify this from the AWS web console by:
Creating a message in a queue.
Viewing the message.
Waiting for the visibility timeout to expire. Once it has, open the SQS console again in a new tab.
Viewing the message again, in the new tab. Compare the contents of both received messages.