supervisor:restart_child/2 (throttling)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

supervisor:restart_child/2 (throttling)

Sean Hinde-2
> Suppose a supervised server tries to acquire some resource when it
> starts, and crashes or terminates if it can't. If the resource is
> unavailable, we don't really want the child to be shut down with
> reached_max_restart_intensity.  The child can avoid this by waiting
> for a fixed time on startup or before crashing, but then the
> availability of the server would be less than optimal (if the child
> has been running correctly for some time, we should try to restart it
> immediately, and begin to delay the restarts only if it keeps
> crashing).

I'd definitely support this. I find I re-write this sort of functionality
quite often and it would be nice to have it formalised into the supervisor
behaviour. e.g. my erpc thing posted recently uses timers to retry a tcp/ip
connection every few seconds. It would have been very nice to just use
supervisor.

This would go hand in hand with having an 'infinity' retries option as
discussed last year some time on the list.

 -Sean



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.



Reply | Threaded
Open this post in threaded view
|

supervisor:restart_child/2 (throttling)

Ulf Wiger-4
On Sun, 25 Feb 2001, Sean Hinde wrote:

>> Suppose a supervised server tries to acquire some resource when it
>> starts, and crashes or terminates if it can't. If the resource is
>> unavailable, we don't really want the child to be shut down with
>> reached_max_restart_intensity.  The child can avoid this by waiting
>> for a fixed time on startup or before crashing, but then the
>> availability of the server would be less than optimal (if the child
>> has been running correctly for some time, we should try to restart it
>> immediately, and begin to delay the restarts only if it keeps
>> crashing).
>
>I'd definitely support this. I find I re-write this sort of functionality
>quite often and it would be nice to have it formalised into the supervisor
>behaviour. e.g. my erpc thing posted recently uses timers to retry a tcp/ip
>connection every few seconds. It would have been very nice to just use
>supervisor.
>
>This would go hand in hand with having an 'infinity' retries option
>as discussed last year some time on the list.


OK, issues with the above:


1) It's not acceptable to block the supervisor while delaying a
   restart. It would have to be done by ordering a timer.

2) If the child crashes and is gone for some time, messages to that
   child will go into the bit bucket, instead of being buffered
   while the child is waiting for the resource.

3) A possibility would be to have the supervisor execute a delay
   in the init function of the process, but then it would first
   have to send an ack to the supervisor so that it's not blocked
   unnecessarily (in general, you don't want to block the
   supervisor for very long)

4) If you _don't_ block the supervisor, then it will proceed to
   start any children that come after this child. This might be
   a desired behaviour, but then again it might not. Of course
   making it an option in the supervisor doesn't preclude either
   behaviour.

/Uffe
--
Ulf Wiger                                    tfn: +46  8 719 81 95
Senior System Architect                      mob: +46 70 519 81 95
Strategic Product & System Management    ATM Multiservice Networks
Data Backbone & Optical Services Division      Ericsson Telecom AB