[erlang-questions] Beginner gen_server and child monitoring
Giovanni Giorgi
jj@REDACTED
Thu Aug 4 17:26:20 CEST 2016
Hi,
First of all thank you to Jesper and Troben.
On 03/ago/2016, at 14:26, Jesper Louis Andersen <jesper.louis.andersen@REDACTED> wrote:
>
> On Thu, Jul 28, 2016 at 7:47 AM, Giovanni Giorgi <jj@REDACTED> wrote:
> Now the question is: Is a correct approach?
>
> The key observation is: "How do you want to handle error in the processes?"
[snip]
> You could simply run the tickers as Torben suggests and then spawn_link them under the main process.
...
> You could also use an asymmetric solution: spawn_monitor the tickers and have the tickers monitor the main process. This allows you to handle the case where you want to restart a crashing ticker for instance, but you have to write the logic yourself.
In my first implementation I am using spawn_monitor because I want to know if some process die, but I do not want to tear down the entire tree for a stupid network error.
I am also thinking to get a stronger child process which will crash only for a very bad error (i.e. out of memory or other important logic error).
I think I need to implement a supervisor-like behavior for the server watching the small processes
>
> In general, spawning processes without knowing where they are only works for processes which are guaranteed to terminate. Otherwise, you end up with process leaks.
I got it.
By the way I am always amaze by how the Erlang language seems like a domain language, because the use of a bunch of right atom give me the freedom to model a problem in an easy to read fashion.
>
> The final solution is to use a supervision tree: have a main_sup with children MainProcess and TickerPool, the latter being a simple_one_for_one supervisor. Each ticker is added into the TickerPool with supervisor:start_child. It is the the most complex solution, but it has an advantage over the simpler methods: it encodes a *policy* in the supervisors for handling failure modes. That is, you can tolerate some tickers dying, but not too many before trying to restart larger parts of the system.
>
> So the TL;DR is to think about the failure mode of the application and write it accordingly.
>
>
> --
> J.
--
Giovanni Giorgi
jj@REDACTED
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160804/2e4c6190/attachment.htm>
More information about the erlang-questions
mailing list