Skip to content

Unable to Receive Response Message from SQS FIFO Queue After Manual Polling

0

Hello AWS Support,

I am experiencing an issue with AWS SQS FIFO queues in my Spring Boot application.

I am using manual polling (using AmazonSQSAsync.receiveMessage()) to send and receive messages from a FIFO queue. I send a request message to the SQS FIFO queue, and I can see the message successfully appear in the queue.

Immediately after sending the message, I try to receive the response by polling the same queue using the receiveMessage() API. However, I am not receiving the expected response message, even though I can confirm via the AWS console that the message is present in the queue.

Details:

Queue Type: FIFO

Access: Manual polling using AmazonSQSAsync.receiveMessage()

Spring Boot version: 2.7.15

AWS SDK version: 1.x

The message is visible in the queue but not being retrieved by the receiver.

Troubleshooting Done:

Verified the message is present in the FIFO queue.

Confirmed no other consumers are consuming from the queue.

Ensured the receiveMessageRequest includes the correct QueueUrl, MaxNumberOfMessages, and WaitTimeSeconds.

Verified the message group ID and deduplication ID are correctly set.

Checked that the message is not stuck in flight or delayed.

Request:

Could you please help me understand why I am not receiving the message even though it's present in the FIFO queue? Is there a known delay or condition under which messages become available to be polled in FIFO queues that might be affecting this behavior?

Any guidance or troubleshooting steps would be appreciated.

Thanks, Arun Kumar N

asked a year ago212 views
2 Answers
0

There are several potential reasons why you're not receiving messages from your FIFO queue despite them being visible in the AWS console:

  1. Message Group ID Behavior: In FIFO queues, if a message with a particular message group ID is in flight (being processed but not yet deleted), no more messages with the same message group ID will be returned until that message is either deleted or becomes visible again after the visibility timeout expires. This maintains the ordering guarantee within message groups.

  2. Short Polling Limitations: If you're using short polling (WaitTimeSeconds set to 0), Amazon SQS only samples a subset of its servers and might not return all available messages in a single request. Subsequent requests will eventually return your messages. Consider using long polling by setting WaitTimeSeconds to a value greater than 0 (up to 20 seconds) to increase the chances of receiving messages.

  3. Visibility Timeout: Messages might have been fetched but not deleted, making them temporarily invisible. Check and adjust the visibility timeout setting for your queue.

  4. FIFO Throughput Limits: By default, FIFO queues support 300 transactions per second per API action. If you're exceeding this limit, you might receive throttling exceptions. Consider using batch operations or enabling high throughput for FIFO queues if needed.

To troubleshoot further:

  • Implement long polling by setting WaitTimeSeconds to a value like 20 seconds
  • Check the ApproximateNumberOfMessagesVisible CloudWatch metric to understand how many messages are actually available to be received
  • Ensure you're properly deleting messages after processing them
  • Verify that your message group ID strategy is appropriate for your use case
  • Check if you're using multiple message group IDs, as this can help with parallel processing

If you're certain the message is in the queue and visible, implementing long polling should help ensure you receive the message.
Sources
Troubleshoot messages not returned for an Amazon SQS ReceiveMessage API call - Amazon Simple Queue Service
Unable to fetch data from SQS queue. | AWS re:Post
Troubleshoot FIFO throttling issues in Amazon SQS - Amazon Simple Queue Service
Amazon SQS short and long polling - Amazon Simple Queue Service

answered a year ago
  • if i use long poll time like upto 60seconds , my server will give timeout error because we kept 30sec for server time

0

How are you verifying that the message is in the queue? If you use the Poll button in the console, it actually reads the message from the queue, making it unavailable for other consumers, i.e., your application, until the visibility timeout expires. So if you have a 30 seconds visibility timeout and you click the button, and then you try to read from the queue, you will not find any message.

Are you using short polling or long polling? Short polling may return no message when there is a small number of messages in the queue, so you should run it multiple times. It is better to use long polling. The allowed values for long polling is up to 20 seconds.

Could it be that you have another message with the same GroupID currently in flight? SQS FIFO does not allow more than a single consumer processing messages from the same group ID.

AWS
EXPERT
answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.