[erlang-questions] Alternative supervision approaches

Ulf Wiger ulf@REDACTED
Thu Jun 26 20:09:07 CEST 2014


On 26 Jun 2014, at 19:16, Jay Nelson <jay@REDACTED> wrote:

> I believe the supervisor and link constructs pre-date monitoring.
> Would supervision have been implemented differently in OTP if
> monitors were available (nudge, Lenart, Francesco)?

As it turns out, supervisors need both links and monitors. Links are needed for cascading exits, and monitors for orderly shutdown. Well, actually, supervisors would need a form of link that the child cannot *unlink*. If it did, it wouldn’t need monitors, and this also makes the cascading exit functionality slightly unsafe.

> 
> Does anyone start supervisors without children and then use an
> external FSM to control starting of children as their approach to
> managing when services are available?

Sure. I do that in kvdb, for example.

> One technique for allowing a service to fail and restart later when
> conditions have changed is to make a restart strategy for the
> supervisor of workers, but make its supervisor use a transient
> strategy. The workers will restart a few times, then the parent
> fails but does not restart. Monitoring plus some strategies for
> altering the setup environment can be used before reinstantiating
> the children on the transient supervisor.
> 
> Anyone else use non-standard supervision approaches they
> would like to share?

I once made an extension to supervisor.erl that allows the child to enquire about the restart history. I’ve found that complex restart scenarios are often frustrated by the fact that the child cannot tell the difference between the first restart and the nth restart following an escalated recovery. There’s something to be said for a brain-dead recovery mechanism, but sometimes, you really, really do need more.

I actually have it lying around somewhere. I posted it to the list, and at some later point, managed to excavate it and save it from oblivion.

BR;
Ulf W

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
http://feuerlabs.com






More information about the erlang-questions mailing list