<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6000.16809" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff
size=2></FONT> </DIV>
<DIV><SPAN class=382223707-23032009><FONT face="Courier New" color=#0000ff
size=2>Hi, there is a reason why there is no terminate function in a supervisor.
For the supervisor recovery schem to be correct (seen from the over all systems
perpective) supervisors *must* be free of errors. That is why the programmer is
not given the chance of writing code that shall be executed in its
context.</FONT></SPAN></DIV>
<DIV><SPAN class=382223707-23032009><FONT face="Courier New" color=#0000ff
size=2>(In the beginning, before someone destroyed it :-) the supervisor was
written completely in its own module. Where there actually was a big part of
copied code from the gen_server and general gen code. The reason for copying the
code was of course to make sure that not something got "improved" when some
other feature in OTP was inteed improved).</FONT></SPAN></DIV>
<DIV><SPAN class=382223707-23032009><FONT face="Courier New" color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=382223707-23032009><FONT face="Courier New" color=#0000ff
size=2>But to your question, no there is no regular way of asking about the
current intensity. But once again as I hinted in the previous mail. There is
nothing that prevents you from adjusting the sliding window to make the
supervisor never escalate restarts.</FONT></SPAN></DIV>
<DIV><SPAN class=382223707-23032009><FONT face="Courier New" color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=382223707-23032009><FONT face="Courier New" color=#0000ff
size=2>Best Regards</FONT></SPAN></DIV>
<DIV><SPAN class=382223707-23032009><FONT face="Courier New" color=#0000ff
size=2>Lennart</FONT></SPAN></DIV>
<DIV><SPAN class=382223707-23032009><FONT face="Courier New" color=#0000ff
size=2></FONT></SPAN> </DIV><!-- Converted from text/plain format -->
<P><FONT face="Courier New"><FONT
size=2>-------------------------------------------------------------------------------<BR>Lennart
Öhman
phone: +46 8 587 623 27<BR>Sjöland & Thyselius Telecom AB cell :
+46 70 552 6735<BR>Hälsingegatan 43, 10th floor
fax : +46 8 667 8230<BR>SE-113 31 STOCKHOLM,
SWEDEN email: lennart.ohman@st.se</FONT>
</FONT></P>
<DIV><FONT face="Courier New"></FONT> </DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> erlang-questions-bounces@erlang.org
[mailto:erlang-questions-bounces@erlang.org] <B>On Behalf Of </B>steve
ellis<BR><B>Sent:</B> den 22 mars 2009 15:58<BR><B>To:</B> Mihai Balea;
erlang-questions@erlang.org<BR><B>Subject:</B> Re: [erlang-questions] to
supervise or not to supervise<BR></FONT><BR></DIV>
<DIV></DIV>Thanks Lennart and Mihai! Very helpful information. Lennart it's good
to know about the intent behind supervisor's orignial design.<BR><BR>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.<BR><BR>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?<BR><BR>It doesn't look like supervisor has a
function like gen_server's handy terminate/2.<BR><BR>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.<BR><BR>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.<BR><BR>Thanks!<BR><BR>Steve<BR><BR>
<DIV class=gmail_quote>On Fri, Mar 20, 2009 at 5:29 PM, Mihai Balea <SPAN
dir=ltr><<A href="mailto:mihai@hates.ms">mihai@hates.ms</A>></SPAN>
wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<DIV>
<DIV></DIV>
<DIV class=h5><BR>On Mar 20, 2009, at 3:42 PM, steve ellis wrote:<BR><BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">New
to supervision trees and trying to figure out when to use them (and when not
to)...<BR><BR>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?<BR><BR>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.<BR><BR>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.<BR><BR>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?<BR></BLOCKQUOTE><BR></DIV></DIV>As far as I know, the standard
supervisor cannot behave the way you want it to.<BR><BR>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.<BR><FONT
color=#888888><BR>Mihai<BR><BR></FONT></BLOCKQUOTE></DIV><BR></BODY></HTML>