1
00:00:00,360 --> 00:00:06,000
In this video, we are going to talk about Amazon Square's short and long polling.

2
00:00:07,470 --> 00:00:12,780
On case provides short polling and long polling to receive messages from the Q.

3
00:00:12,990 --> 00:00:16,230
By default, crews are using short polling.

4
00:00:17,020 --> 00:00:22,690
With the short polling, the received message requests query is only a subset of the servers to find

5
00:00:22,690 --> 00:00:26,080
messages that are available to include in the response.

6
00:00:27,000 --> 00:00:32,970
Almost an exquisite sense, the response right away, even if the query found no message.

7
00:00:33,600 --> 00:00:36,830
But with long polling, the receive message requests.

8
00:00:36,840 --> 00:00:37,560
Queries.

9
00:00:37,560 --> 00:00:39,600
All of the servers for messages.

10
00:00:40,860 --> 00:00:47,550
Amazon sent a response after it, collecting at least one available message up to the maximum number

11
00:00:47,550 --> 00:00:49,500
of messages specified in the request.

12
00:00:50,090 --> 00:00:55,850
But almost in this case sense an empty response only if the polling wait time expires.

13
00:00:57,100 --> 00:01:03,310
So if you look at the consuming message using the short link, when you consume message from the queue,

14
00:01:03,340 --> 00:01:11,140
using the short link, Amazon samples a subset of each service based on a weighted random distribution

15
00:01:11,140 --> 00:01:14,380
and return message from the only dose service.

16
00:01:15,870 --> 00:01:21,960
By this way, a particular resume message request might not be return all of to your message.

17
00:01:21,990 --> 00:01:28,440
However, if you have fewer than 1000 messages in your queue, a subsequent request will return your

18
00:01:28,440 --> 00:01:29,130
messages.

19
00:01:29,950 --> 00:01:37,900
If you keep consuming from your cuz Amazon samples all of its servers and you receive all of your messages.

20
00:01:39,860 --> 00:01:46,100
So if you look at the cosmic message the using long link one, the wait time for the receive message

21
00:01:46,100 --> 00:01:48,290
API action is greater than zero.

22
00:01:48,320 --> 00:01:50,390
Long polling is in effect.

23
00:01:50,630 --> 00:01:53,870
The maximum long wait time is 20 seconds.

24
00:01:53,960 --> 00:02:00,560
Long polling helps reduce the cost of using Amazon space by eliminating the number of empty responses.

25
00:02:01,430 --> 00:02:06,260
So long polling is the best practice and long polling offers the following benefits.

26
00:02:06,260 --> 00:02:08,060
Basically, it is followed.

27
00:02:08,060 --> 00:02:14,810
The benefits are reduced to empty responses by allowing Amazon space to wait until a message is available

28
00:02:14,810 --> 00:02:17,060
in the queue before sending a response.

29
00:02:17,450 --> 00:02:23,420
Unless the connection times out, the response to the receive message request contains at least one

30
00:02:23,420 --> 00:02:29,300
of the available message up to the maximum number of the message specified in the receive message action.
