Elixir Supervisor

in elixir there is a big chance the term fault-tolerance is mentioned when discussing the merits of this language it's rare for a language to have process monitoring and responsibility hierarchy built right into the core this presentation is going to introduce the concepts and syntax of Supervisors go over available supervision strategies and restart options and introduce a few methods and examples gent server ideas are at the heart of the supervisor module if you are new to Gen Server please check out previous videos in this series that introduce gen server concepts like callbacks and concurrency this is a basic example of a supervisor you can see that structurally it resembles the gen server quite a bit here we have a module that is going to use elixir supervisor behavior you can see that it has a start link method that starts a supervisor process and it has an init callback method that runs when you call start link when you run it and it starts successfully it returns ok and process ID just like the gen server inside the init method however things are quite a bit different at the end of the initialization we call the supervised method to which we passed the children and a strategy argument in the supervisor context children refer to the processes directly under its supervision and you are required to declare at least one shout process in this example the list of children contains just one element which is this gen server a supervisor is also able to monitor other supervisors which will look after its children but however this particular supervisor is directly responsible for will be defined inside of this list if you have the required argument for the supervised method is the strategy the strategy defines what happens when one of the children is terminated we're going to go over each strategy in detail for now let's go back to the list of children the goal of every child element is to define a template for the monitored process in this example we only define one worker the worker method takes a module and a list of elements to pass to this module as arguments when it starts up by default the method that will be called to start this worker process is start linked and this list contains the arguments they'll be passed to it this could be a bit confusing we are not going to pass an empty list as an argument we are not going to pass any arguments at all in this case you see that the start link method on the basic gen server does not expect to take any arguments a more elixir way to say this would be that the empty list here would be calling a basic module start link method was zero arity if this would contain one element that element is what will be passed to the start link method here two elements inside of this list would mean two arguments and so on you could also define a keyword list here but it would have to be nested inside of this list otherwise each pair would be treated as a separate argument double now let's talk about the different supervision strategies we have one for one that means when any of the supervised processes terminates it will be restarted one for all meaning if any one of the children terminates all processes will be restarted rest for one which is similar to one for all but instead of all processes being restarted only once defined below the process that terminates a restarted we're going to go over each one of these in more detail one other supervision strategy is simple one for one this one is the most special because it's meant for managing multiple child processes of the same type which will be started and stopped dynamically let's modify the basic supervisor module by adding a few more children processes each child is going to be a different gen server module but each one won't be doing anything besides output the module name when it starts up having multiple children processes should help visualize the differences between the supervision strategies let's go over a few helpful methods first we are going to run basic supervisors start link you should see output of all four monitored processes at this point it's important to note that for all strategies except simple one for one supervisors start link starts all children processes as well when they all started successfully you will see okay and the supervisor process ad elixir process module has an alive method to check if a process is running it just returns a boolean this method can be used on any elixir process and now the method we're going to use is which children notice that this method is called an elixirs supervisor module and not on a basic supervisor module that we defined this method returns a list of tuples containing information about each supervisor process knowing that there will only be four elements here we can grab all four at the same time notice that even though the children processes started in the order that were defined basic one process is the last element in this list since we are only interested in its process ad and we know that each one of these tuples has four elements we can pattern match this tuple and grab basic one process ID just to confirm it you can see that this variable does contain the pig for this process to demonstrate the supervisor actions we're going to use gen service stop method to stop the process and watch what happens now let's apply these methods on each one of the strategies beginning with one for one strategy we start a supervisor process run which children method to capture all the worker processes and select the first worker pit that's actually the last element in the list and now let's stop this worker by calling gen server stop when you run this you should see basic one is starting printed on the screen which means that worker process was restarted so we stopped a worker process manually and the supervisor found out about it and restarted it if we check to see if one pit is still alive it's not since that's the process that was stopped when we grab the active children or the supervisor again we can see that in that list every process ID stayed the same except for the basic one process so when one of the monitored processes terminates only that processes were started this strategy is used when a supervisor only monitors one process or when all monitored processes don't rely on each other in any way let's repeat these actions for a one for all strategy we start the supervisor grab the children which gives us a list again and just like before grab the pit of the basic one worker when you stop it all worker processes will be stopped and you will see starting messages for all of them meaning they were all restarted once again checking if one pit is alive is false and when you select the children you will see that all process IDs are now different rest for one will be very similar we start the supervisor grab the children and get a list this time though we're going to grab the pit of the basic to process when you stop it all processes defined below it will be stopped when they get restarted you will see the starting messages four processes two three and four basic one process was left alone because it was defined above the process that was stopped when you grab the children again you will see that all process IDs except for basic one are now different let's recap the strategies we learned so far one for one strategy restarts the process and just the process that was stopped one for all strategy restarts all the processes for anyone that goes down rest for one strategy restarts the process that went down and all the ones defined below it before moving on to talk about simple one for one strategy I want to mention an option that could be passed to the Walker method the worker method could take an optional restart argument that would define the restart conditions for that process permanent is the default for one for one one for all and rest for one the ones we've covered so far it means that no matter how the process gets terminated whether it crashed or simply shut down it will be restarted transient is the default for simple one for one it means that the process will only be restarted if it crashed if we would have set that option for any one of our workers here they would not be restarted because we've been shutting them down nicely the third restart option is temporary in this case the process would not be restarted under any circumstances if it crashes or gets simply shut down the supervisor will not restarted I also want to mention that the restart argument takes precedence over the strategy so even if the strategies want for all the process would only be restarted if it's compatible with its restart setting so now let's talk about the simple one for one strategy simple one for one only allows one worker to be defined when you started and run which children you'll get an empty list unlike the other strategies a worker will not be started when you start a supervisor in order to start a worker process you'll need to call a supervisor start child method with the supervisor ID when you run it you'll see basic one is starting printed out and ok and the worker process idea will be returned you are not limited to just one child process however simple one for one strategy is meant for monitoring multiple processes of the same kind so you could start multiple basic one workers by running supervisor start child again and again you will see basic one is starting printed out and the new process ID is the response value note that we are not specifying anything about the worker process when running start child method because we define the strategy as simple one for one the supervisor knows that we want to start another worker of that same type now when you run supervisor of which children you'll get a list containing the process IDs of the workers we just started knowing there are only two we could grab them and get an ID out of one of them so now if you want to shut down one of the workers you would run supervisor terminate child notice that this is a supervisor method and not a gen server method running which children again you'll see that we only have one process remaining simple one for one strategy is great when you need to fluctuate a number of workers you may need more or less due to some kind of demand or simply want to start a unique session for a given user or game or something like that we covered a variety of ways a supervisor could monitor processes the real power of supervision however comes from building layers of hierarchy where the supervisor could watch not just worker processes but other supervisors as well creating a robust and a fault-tolerant system in the real application workers need to be able to communicate with each other the way that were defined in our examples that would be pretty impractical in order to find the process ID for every worker we need to look up at supervisor get the children and parse that list that could get pretty complicated in a sizeable hierarchy luckily elixir provides a way to register processes so that it's ad would be associated with a module name an atom or even a custom strength which would be great for dynamic workers but let's discuss that in another time at this point you know the main building blocks of elixir OTP applications the goal of this tutorial was to make sure that the structure and the syntax of Supervisors make sense and you're able to figure out how to get wired up I hope you continue exploring elixir and are excited about the tools this language has to offer thank you for watching

Channel: omgneering

Views: 8,841

Rating: 5 out of 5

Keywords: elixir, otp, gen_server, gen, server, genserver, supervisor, process, monitoring

Id: Gdf8JXeaPjw

Length: 13min 31sec (811 seconds)

Published: Tue Dec 20 2016

Reddit Comments

[u/quaunaut]

This was a fantastic primer on Supervisors. As I've been spending more and more time in Elixir, there's a lot of small building blocks that as much as I vaguely understand their documentation, seeing direct results works out a lot better.

Thanks!

[u/zachgarwood]

I really like this series. Keep it up!