[erlang-questions] to supervise or not to supervise

[Serge Aleynikov]

Could you point me to a link with implementation of that alternative 
supervisor?  The link below didn't have an attachment.

I've been considering to rewrite the timed_supervisor [*] I wrote some 
time ago so that instead of being modeled after gen_server-like 
supervisor_bridge it would be a more native supervisor replacement. 
Perhaps I should use a subset of your supervisor's child specification 
configuration.

[*] http://forum.trapexit.org/viewtopic.php?p=44147#44147

Serge

Ulf Wiger wrote:
> So when this question comes up it is customary for me to mention
> my extension of the supervisor behavior to allow tracking the number
> of restarts... (:
> 
> http://erlang.org/pipermail/erlang-questions/2003-November/010763.html
> 
> The way restart escalation currently works, I think it's wise in most cases
> to escalate all the way up as soon as the nearest supervisor is unable
> to resolve the situation. I've rarely seen an escalated issue resolve itself
> in the middle management layer. You either solve it close to the problem
> itself, or you solve it at the top - and try to expedite the work in the
> middle.
> 
> (We're of course only talking Erlang supervisors here.)
> 
> BR,
> Ulf W
> 
> 
> 2009/3/22 steve ellis <steve.e.123@REDACTED>:
>> Thanks Lennart and Mihai! Very helpful information. Lennart it's good to
>> know about the intent behind supervisor's orignial design.
>>
>> I like Mihai's suggestion of having one supervisor supervise each process.
>> This would get us most of the way there and it would be easy to implement.
>>
>> But is there any way in OTP to see when a supervisor reaches its max
>> restarts? I know this is logged by the sasl error logger. But how would I
>> trap/detect this event in my code to do something with it?
>>
>> It doesn't look like supervisor has a function like gen_server's handy
>> terminate/2.
>>
>> Maybe it would make more sense in our case to have one gen_server process
>> monitor a child gen_server process. The child could call a function in the
>> parent when it terminates. This way we'd have access to the terminate
>> function of the monitoring/supervising gen_server. The problem with this
>> though is that we'd have to implement our own restart strategy behavior,
>> which is what is so great about supervisor.
>>
>> This might be related to something more general that I've been wondering
>> about (which I should post as a question in a new thread). How to tap into
>> the sasl error logger so my system can do stuff with those events. For
>> example I'd like to send these events to another machine via tcp.
>>
>> Thanks!
>>
>> Steve
>>
>> On Fri, Mar 20, 2009 at 5:29 PM, Mihai Balea <mihai@REDACTED> wrote:
>>> On Mar 20, 2009, at 3:42 PM, steve ellis wrote:
>>>
>>>> New to supervision trees and trying to figure out when to use them (and
>>>> when not to)...
>>>>
>>>> I have bunch of spawned processes created through spawn_link. Want these
>>>> processes to say running indefinitely. If one exits in an error state, we
>>>> want to restart it N times. After N, we want to error log it, and stop
>>>> trying to restart it. Perfect job for a one_to_one supervisor right?
>>>>
>>>> Well sort of. The problem is that when the max restarts for the error
>>>> process is reached, the supervisor terminates all its children and itself.
>>>> Ouch! (At least in our case). We'd rather that the supervisor just keep
>>>> supervising all the children that are ok and not swallow everything up.
>>>>
>>>> The Design Principles appear to be saying that swallowing everything up
>>>> is what supervisors are supposed to do when max restarts is reached which
>>>> leaves me a little puzzled. Why would you want to kill the supervisor just
>>>> because a child process is causing trouble? Seems a little harsh.
>>>>
>>>> Is this a case of me thinking supervisors are good for too many things?
>>>> Is it that our case is better handled by simply spawning these processes and
>>>> trapping exits on them, and restarting/error logging in the trap exit?
>>> As far as I know, the standard supervisor cannot behave the way you want
>>> it to.
>>>
>>> So, at least until this type of behavior is added to the standard
>>> supervisor, you can work around it with double layers of supervision.
>>>  Basically have one dedicated supervisor for each process you want to
>>> supervise and, in turn, each dedicated supervisor is set up as a transient
>>> child to one big supervisor.
>>>
>>> Mihai
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>