[erlang-questions] simple_one_for_one supervisor - what happens at restart? (also: gen_tcp)

[Oliver Korpilla]

Hello, 

and thank you all for your responses.

I originally adopted simple_one_for_one supervisor because I had a problem with how other supervisors clean up processes. 

For the TCP connectors simple_one_for_one will be fine. As noted by others, they cannot really come back unless they reconnect, so that is fine. So, a simple_one_for_one supervisor acts like every child, regardless of child spec, as if it was temporary?

I have another big batch of processes independent of the connectors. These serve individual requests emanating from the TCP layer, where an ID establishes which handler belongs to which batch of messages (i.e. each TCP payload contains an ID in its own proprietary header). Now, I originally saw these as transient workers I would like to have restarted, but since they are stateless and can be created on demand, I either can supervise them simple_one_for_one (and create them on demand when the one for a given ID is missing) or I can create them as transient children under a one_for_one and let that restart it on a crash.

I originally went for simple_one_for_one because of the better performance and because it cleans up children after they terminate. I guess in case of one_for_one I have to clean up all children which shut down normally by calling terminate_child and delete_child on them. (I originally hoped one_for_one would do this if a child exited normally, but either I bungled my tests or it simply doesn't, even for transient children).

Any recommendations?

Thanks,
Oliver
 

Gesendet: Samstag, 14. Mai 2016 um 12:48 Uhr
Von: "Jesper Louis Andersen" <jesper.louis.andersen@REDACTED>
An: Chandru <chandrashekhar.mullaparthi@REDACTED>
Cc: "Erlang-Questions Questions" <erlang-questions@REDACTED>
Betreff: Re: [erlang-questions] simple_one_for_one supervisor - what happens at restart? (also: gen_tcp)

 
On Sat, May 14, 2016 at 9:46 AM, Chandru <chandrashekhar.mullaparthi@REDACTED> wrote:Cleanup can be done in the terminate callback if you use process_flag(trap_exit, true).
There is a subtlety here which, in some circumstances, creates trouble and one has to be aware of. This is in addition to what Loïc mentions.

Observation: In many systems, processes have dependencies and needs each other to operate. Nice cleanup cannot be done in the situation where your immediate dependencies are gone, but under a controlled shutdown, you can arrange the shutdown order such that the shutdown is graceful.
 
Example: You are processing some kind of request in a web server. You decide to close down the application. Now, what you want to happen is a graceful shutdown: you stop accepting new requests, but you run the current requests to an end (up to some timeout). In settings where the server count is very dynamic and servers can get "elastically" added or removed, this is important because otherwise you would be losing requests under shutdown.
 
Observation: processes under supervision have an ordering imposed on them. Their termination happens in the opposite order of spawning. This can be used to enforce the gracefulness constraint.
 
Another trick, which works cross-application, is to use the Module:prep_stop/1 phase of termination to tell your other applications (ranch, cowboy, yaws) that they should start graceful termination of their workers. Once completed, you can stop your own supervision tree.
 
"Naked" processes which are not linked into a supervision tree can terminate in any order they see fit. In particular, the Erlang VM regards itself as being "done" once all its applications are shut down. In particular a line process with process_flag(trap_exit, true) waiting on disk is not going to be allowed to hold up termination of the VM. A naked process has its use, but one has to be extremely careful around them. If they start failing, you have no easy way to know what their relation is.

 --
J._______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]