you
welcome to the last section on our trip
working with common patterns in Makkah
in the previous section we have
introduced acha HTTP module and we have
worked with the client-side and
server-side api's and also implemented
REST API and test cases for it in the
last section of our course we will take
a look at some of the common patterns on
occur such as balancing work load across
nodes throttling messages shut down
patterns ordered termination and finally
scheduling periodic messages let's start
with balancing work load across nodes in
this first video in this video first we
will quickly go through balancing the
dispatcher then we will take an overview
on the pattern and finally we will check
the implementation let's revise the
balancing dispatcher Rooter which we saw
in one of the previous sections
balancing Rooter dispatches a message to
an actor only when that actor would
otherwise be idle and of course we
remember all our actors shared with the
mailbox if we want to distribute work
over remote actors you can't use
balancing dispatcher because every act
on each node has a different mailbox so
if you want to use balance work with
remote actors you should use the work
pulling pattern which has been described
first by Derek Wyatt let's take a quick
overview before checking the
implementation we will have a master
actor that will coordinate work and have
some of the workers that will execute
the work and these workers work on
different nodes the main goal is to
implement the main fundamental concept
of balancing dispatcher with remote
actors so when the requestor actor sends
a message to our master the master
doesn't route this message immediately
to any workers the master will wait
until one of the worker sends a request
to work so let's assume worker one on
node one finishes his work and it will
be idle so it will send a message to the
master to request a new work the mast
will send a work to this worker when
worker one finishes this work it will
send work done intimation
this is the main idea of this pattern
but in order for the pattern to be valid
we must have concrete instances of the
master on some node and the workers on
the same node or other nodes and when
the worker starts working it must
identify itself to the master so each
worker must know the location of his
master and the master must be running
before the workers tried to register
with it now let's check the basic
implementation of this pattern here is
the protocol between master and worker
these are the messages from a worker
worker created worker requests work and
work is done and these are the messages
from master to worker work to be done
work is ready and no work to be done
here is the implementation of the master
we have workers variable that holds all
workers and the work they may perform on
it and we have work skewed that
represents the received work and here is
the notify worker method that is
responsible for sending workers ready
message for each worker if the master
has work on the queue here is the
implementation for receive when mast
receives the worker created message it
should have a watch on the new worker
and then add it to workers and call the
notify workers method when it receives
the worker requests work message it
should check whether this worker is
present on its workers then if the work
queue is empty it will send no work to
be done to this worker but if the work
queue isn't empty and this worker
doesn't have a work it will DQ a work
from the work queue assign this work for
the worker and send it to this worker
when it receives the work done it will
check whether this worker is present on
its workers or not if this worker
doesn't exist it will log and if it
contains on the workers it will update
the assigned work when the receive has
terminated it will check whether the
terminated worker has work or not if it
was working on something the Master will
send this work for himself and then the
master will remove this worker and
unwatched anything else will add it on
work queue and notify all workers here
is the implementation of the worker we
implemented worker as an abstract class
because we should implement the do work
man
that execute the actual work the worker
takes the masterpath on the constructor
and here to take actor f4 master from
actor path in the pre-start method it
will send were created to the master our
worker has two states which are working
and idle in the working mode we will
ignore any message except work complete
which is sent by the worker itself when
he finishes its work when it is received
the worker will send work is done and
work a request work to the master and
switch itself to idle mode in the idle
mode when the worker receives the work
is ready message from the master it will
send worker request work to the master
and when the worker receives work to be
done we will call the do work method and
switch it to the working mode if it
receives no work to be done we will
ignore it that is the basic
implementation for this pattern at the
end of the video we express balancing
work load across node patterns you can
check all details for this pattern from
here