Consume messages from a queue and its channels.
A response to a
GetMessages request contains the list of messages with their payload, message ID, expiration time, visibility timeout, delivery count, and a
receipt. The maximum number of messages that can be returned in one response is 20, but the actual number of messages returned depends on the number of available messages and whether the request used long polling.
Consumers can "lock" a message retrieved from the queue so that another consumer can't retrieve the same message. Messages are locked by specifying a visibility timeout. The Queue API uses the
visibilityInSeconds parameter to set this value.
The visibility timeout can be set at the queue level when creating a queue, or it can be specified when consuming or updating messages. If a consumer is having difficulty successfully processing a message, it can update the message to extend its invisibility. If a message's visibility timeout isn't extended, and the consumer doesn't delete the message, it returns to the queue.
When consuming, you don't need to specify the visibility timeout. The visibility timeout configured for the queue applies to the request. When creating a queue, the default visibility timeout is 30 seconds. If you include the optional visibility timeout parameter in a request, you can specify a minimum value of 0 seconds and a maximum value of 12 hours.
Using a visibility timeout of 0 effectively acts as a peek functionality. Messages retrieved this way will most likely be delivered to another consumer, because their visibility doesn't change.
Each time a message is retrieved using a
GetMessages request, or by Console polling, its delivery count increases. If the delivery count exceeds the queue's configured maximum, the message is sent to the dead letter queue.
By default, a
GetMessages request uses long polling. The request waits for messages for 30 seconds, and if the timeout passes and no messages are available for consumption, the request returns an empty response. Long polling is useful to prevent tight loop retries on empty responses.
Consumers can change this behavior by including the
timeoutInSeconds parameter in their request, which accepts values of 0 to 30 seconds. Setting the
timeoutInSeconds value to 0 results in an immediate response from the queue, whether or not there are messages available.