1
00:00:00,210 --> 00:00:04,799
you

2
00:00:04,799 --> 00:00:07,240
welcome to the last section on our trip

3
00:00:07,240 --> 00:00:09,490
working with common patterns in Makkah

4
00:00:09,490 --> 00:00:12,070
in the previous section we have

5
00:00:12,070 --> 00:00:14,859
introduced acha HTTP module and we have

6
00:00:14,859 --> 00:00:16,179
worked with the client-side and

7
00:00:16,179 --> 00:00:19,689
server-side api's and also implemented

8
00:00:19,689 --> 00:00:23,469
REST API and test cases for it in the

9
00:00:23,469 --> 00:00:25,480
last section of our course we will take

10
00:00:25,480 --> 00:00:27,129
a look at some of the common patterns on

11
00:00:27,129 --> 00:00:30,640
occur such as balancing work load across

12
00:00:30,640 --> 00:00:34,359
nodes throttling messages shut down

13
00:00:34,359 --> 00:00:38,140
patterns ordered termination and finally

14
00:00:38,140 --> 00:00:42,579
scheduling periodic messages let's start

15
00:00:42,579 --> 00:00:44,978
with balancing work load across nodes in

16
00:00:44,978 --> 00:00:48,939
this first video in this video first we

17
00:00:48,939 --> 00:00:50,439
will quickly go through balancing the

18
00:00:50,439 --> 00:00:53,018
dispatcher then we will take an overview

19
00:00:53,018 --> 00:00:56,018
on the pattern and finally we will check

20
00:00:56,018 --> 00:00:58,869
the implementation let's revise the

21
00:00:58,869 --> 00:01:01,088
balancing dispatcher Rooter which we saw

22
00:01:01,088 --> 00:01:02,728
in one of the previous sections

23
00:01:02,728 --> 00:01:05,409
balancing Rooter dispatches a message to

24
00:01:05,409 --> 00:01:07,359
an actor only when that actor would

25
00:01:07,359 --> 00:01:10,239
otherwise be idle and of course we

26
00:01:10,239 --> 00:01:12,129
remember all our actors shared with the

27
00:01:12,129 --> 00:01:14,799
mailbox if we want to distribute work

28
00:01:14,799 --> 00:01:17,049
over remote actors you can't use

29
00:01:17,049 --> 00:01:19,328
balancing dispatcher because every act

30
00:01:19,328 --> 00:01:22,840
on each node has a different mailbox so

31
00:01:22,840 --> 00:01:24,728
if you want to use balance work with

32
00:01:24,728 --> 00:01:26,828
remote actors you should use the work

33
00:01:26,828 --> 00:01:28,780
pulling pattern which has been described

34
00:01:28,780 --> 00:01:32,049
first by Derek Wyatt let's take a quick

35
00:01:32,049 --> 00:01:33,340
overview before checking the

36
00:01:33,340 --> 00:01:35,739
implementation we will have a master

37
00:01:35,739 --> 00:01:38,560
actor that will coordinate work and have

38
00:01:38,560 --> 00:01:40,030
some of the workers that will execute

39
00:01:40,030 --> 00:01:42,159
the work and these workers work on

40
00:01:42,159 --> 00:01:44,709
different nodes the main goal is to

41
00:01:44,709 --> 00:01:46,599
implement the main fundamental concept

42
00:01:46,599 --> 00:01:48,489
of balancing dispatcher with remote

43
00:01:48,489 --> 00:01:52,060
actors so when the requestor actor sends

44
00:01:52,060 --> 00:01:54,069
a message to our master the master

45
00:01:54,069 --> 00:01:55,478
doesn't route this message immediately

46
00:01:55,478 --> 00:01:58,450
to any workers the master will wait

47
00:01:58,450 --> 00:02:00,039
until one of the worker sends a request

48
00:02:00,039 --> 00:02:03,248
to work so let's assume worker one on

49
00:02:03,248 --> 00:02:05,769
node one finishes his work and it will

50
00:02:05,769 --> 00:02:07,868
be idle so it will send a message to the

51
00:02:07,868 --> 00:02:10,780
master to request a new work the mast

52
00:02:10,780 --> 00:02:13,030
will send a work to this worker when

53
00:02:13,030 --> 00:02:15,280
worker one finishes this work it will

54
00:02:15,280 --> 00:02:17,599
send work done intimation

55
00:02:17,599 --> 00:02:19,699
this is the main idea of this pattern

56
00:02:19,699 --> 00:02:21,889
but in order for the pattern to be valid

57
00:02:21,889 --> 00:02:24,080
we must have concrete instances of the

58
00:02:24,080 --> 00:02:26,930
master on some node and the workers on

59
00:02:26,930 --> 00:02:30,259
the same node or other nodes and when

60
00:02:30,259 --> 00:02:32,419
the worker starts working it must

61
00:02:32,419 --> 00:02:35,030
identify itself to the master so each

62
00:02:35,030 --> 00:02:36,740
worker must know the location of his

63
00:02:36,740 --> 00:02:38,780
master and the master must be running

64
00:02:38,780 --> 00:02:40,069
before the workers tried to register

65
00:02:40,069 --> 00:02:43,159
with it now let's check the basic

66
00:02:43,159 --> 00:02:45,680
implementation of this pattern here is

67
00:02:45,680 --> 00:02:47,719
the protocol between master and worker

68
00:02:47,719 --> 00:02:49,550
these are the messages from a worker

69
00:02:49,550 --> 00:02:52,789
worker created worker requests work and

70
00:02:52,789 --> 00:02:55,219
work is done and these are the messages

71
00:02:55,219 --> 00:02:57,530
from master to worker work to be done

72
00:02:57,530 --> 00:03:00,699
work is ready and no work to be done

73
00:03:00,699 --> 00:03:03,289
here is the implementation of the master

74
00:03:03,289 --> 00:03:05,930
we have workers variable that holds all

75
00:03:05,930 --> 00:03:08,000
workers and the work they may perform on

76
00:03:08,000 --> 00:03:10,219
it and we have work skewed that

77
00:03:10,219 --> 00:03:12,830
represents the received work and here is

78
00:03:12,830 --> 00:03:14,509
the notify worker method that is

79
00:03:14,509 --> 00:03:16,280
responsible for sending workers ready

80
00:03:16,280 --> 00:03:18,530
message for each worker if the master

81
00:03:18,530 --> 00:03:21,409
has work on the queue here is the

82
00:03:21,409 --> 00:03:23,900
implementation for receive when mast

83
00:03:23,900 --> 00:03:25,969
receives the worker created message it

84
00:03:25,969 --> 00:03:27,379
should have a watch on the new worker

85
00:03:27,379 --> 00:03:29,750
and then add it to workers and call the

86
00:03:29,750 --> 00:03:32,330
notify workers method when it receives

87
00:03:32,330 --> 00:03:34,250
the worker requests work message it

88
00:03:34,250 --> 00:03:35,629
should check whether this worker is

89
00:03:35,629 --> 00:03:38,569
present on its workers then if the work

90
00:03:38,569 --> 00:03:40,789
queue is empty it will send no work to

91
00:03:40,789 --> 00:03:43,789
be done to this worker but if the work

92
00:03:43,789 --> 00:03:45,500
queue isn't empty and this worker

93
00:03:45,500 --> 00:03:47,930
doesn't have a work it will DQ a work

94
00:03:47,930 --> 00:03:50,240
from the work queue assign this work for

95
00:03:50,240 --> 00:03:52,509
the worker and send it to this worker

96
00:03:52,509 --> 00:03:55,280
when it receives the work done it will

97
00:03:55,280 --> 00:03:56,900
check whether this worker is present on

98
00:03:56,900 --> 00:03:59,240
its workers or not if this worker

99
00:03:59,240 --> 00:04:01,849
doesn't exist it will log and if it

100
00:04:01,849 --> 00:04:03,680
contains on the workers it will update

101
00:04:03,680 --> 00:04:06,620
the assigned work when the receive has

102
00:04:06,620 --> 00:04:08,419
terminated it will check whether the

103
00:04:08,419 --> 00:04:11,569
terminated worker has work or not if it

104
00:04:11,569 --> 00:04:13,610
was working on something the Master will

105
00:04:13,610 --> 00:04:16,850
send this work for himself and then the

106
00:04:16,850 --> 00:04:18,379
master will remove this worker and

107
00:04:18,379 --> 00:04:21,319
unwatched anything else will add it on

108
00:04:21,319 --> 00:04:24,529
work queue and notify all workers here

109
00:04:24,529 --> 00:04:26,779
is the implementation of the worker we

110
00:04:26,779 --> 00:04:28,879
implemented worker as an abstract class

111
00:04:28,879 --> 00:04:31,069
because we should implement the do work

112
00:04:31,069 --> 00:04:31,439
man

113
00:04:31,439 --> 00:04:34,199
that execute the actual work the worker

114
00:04:34,199 --> 00:04:36,240
takes the masterpath on the constructor

115
00:04:36,240 --> 00:04:39,509
and here to take actor f4 master from

116
00:04:39,509 --> 00:04:42,810
actor path in the pre-start method it

117
00:04:42,810 --> 00:04:44,939
will send were created to the master our

118
00:04:44,939 --> 00:04:47,639
worker has two states which are working

119
00:04:47,639 --> 00:04:50,910
and idle in the working mode we will

120
00:04:50,910 --> 00:04:53,189
ignore any message except work complete

121
00:04:53,189 --> 00:04:55,620
which is sent by the worker itself when

122
00:04:55,620 --> 00:04:58,079
he finishes its work when it is received

123
00:04:58,079 --> 00:05:00,240
the worker will send work is done and

124
00:05:00,240 --> 00:05:02,639
work a request work to the master and

125
00:05:02,639 --> 00:05:06,389
switch itself to idle mode in the idle

126
00:05:06,389 --> 00:05:08,129
mode when the worker receives the work

127
00:05:08,129 --> 00:05:10,379
is ready message from the master it will

128
00:05:10,379 --> 00:05:12,540
send worker request work to the master

129
00:05:12,540 --> 00:05:15,480
and when the worker receives work to be

130
00:05:15,480 --> 00:05:17,910
done we will call the do work method and

131
00:05:17,910 --> 00:05:20,550
switch it to the working mode if it

132
00:05:20,550 --> 00:05:22,379
receives no work to be done we will

133
00:05:22,379 --> 00:05:24,629
ignore it that is the basic

134
00:05:24,629 --> 00:05:27,660
implementation for this pattern at the

135
00:05:27,660 --> 00:05:29,850
end of the video we express balancing

136
00:05:29,850 --> 00:05:32,220
work load across node patterns you can

137
00:05:32,220 --> 00:05:33,870
check all details for this pattern from

138
00:05:33,870 --> 00:05:35,064
here