mdivk
mdivk

Reputation: 3727

Why one SQS message doesn't get deleted while others do?

I came across this question in my AWS study:

You create an SQS queue and decide to test it out by creating a simple application which looks for messages in the queue. When a message is retrieved, the application is supposed to delete the message. You create three test messages in your SQS queue and discover that messages 1 and 3 are quickly deleted but message 2 remains in the queue. What is a possible cause for this behavior? Choose the 2 correct answers

Options:
A.  The order that messages are received in is not guaranteed in SQS
B.  Message 2 uses JSON formatting
C.  You failed to set the correct permissions on message 2
D.  Your application is using short polling 

Correct Answer:

A. The order that messages are received in is not guaranteed in SQS
D. Your application is using short polling

Why A is considered as one the answer here? I understand A is correct from the SQS feature definition, however, it does not explain to the issue in this question, right? Why it is not the permission issue?

Anything I am missing?

Thank you.

Upvotes: 1

Views: 166

Answers (1)

John Rotenstein
John Rotenstein

Reputation: 269081

I think that a justification for A & D is:

  • Various workers might be pulling messages from the queue
  • Given that it is not a FIFO queue, then message order is not guaranteed (A)
  • Short-polling will not necessarily check every 'server', it will simply return a message (D)
  • Message 2 simply hasn't been processed yet

Frankly, I don't think that D is so relevant, because Long Polling returns as soon as it gets a message and it simply means that no worker has requested the message yet.

B is irrelevant because message content has no impact on retrieval.

C is incorrect because there are no permissions on individual messages. Only the queue, or users accessing the queue, have permissions.

Upvotes: 1

Related Questions