I don’t understand the need to configure short and long polling directly on the queue.
Say I create an sqs queue and I want to check the queue for messages once every hour with java.
Then I just need to create a method annotated with @Scheduled(fixedRate = 3600000) and in the method I call sqsClient.receiveMessage and that’s it.
If I want short polling then I can just reduce the fixedRate to call my method every 5 seconds for example.
I already read:
waitTimeSeconds(): The duration (in seconds) for which the call waits
for a message to arrive in the queue before returning.When passing a value for waitTimeSeconds (maximum of 20 seconds), the
call will block while there are no messages available in the queue.
However, if there is a message (or a message comes during that time
period), it will immediately return with messages.
What is it, another polling configuration within my polling configuration with @Scheduled ? I don’t get it. Also the max value is 20 seconds and I really don’t need to check my queue that frequently.
So do I just set Receive message wait time to 1 so I get the specificities of long polling (check all servers for messages) and ignore its existence because I don’t need it ?
What is the usecase of it ?
2
Answers
If your requirement is to check for messages every hour, then
waitTimeSeconds()is not relevant for you.It is normally used in high-volume situations where messages are continuously wanted. For this, a ‘consumer’ is written that keeps polling the queue. To minimise the number of calls, a Wait Time of up to 20 seconds can be specified.
By specifying a Wait Time it is saying: "If there are no messages in the queue, wait 20 seconds before providing a response to this API call. However, please return immediately if a message becomes available."
The use-case would be for a system that wants to respond very quickly when a message enters the queue.
Short polling, is used when ‘the client’ wants to get/process every message as fast as possible (low latency).
Long polling is used when AWS wait for X seconds, before the poll request returns data. This is rarely used, as it required a timeout to occur before the messages are processed. Theoretically, this may yield higher throughput, but only in scenarios where the queue is fully loaded, which is quite rare.