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 ?
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.