[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
autorespawn for crashed modules
From: |
Klaus Knopper |
Subject: |
autorespawn for crashed modules |
Date: |
Tue, 5 Oct 2010 15:47:43 +0200 |
On Tue, Oct 05, 2010 at 12:25:38PM +0200, Halim Sahin wrote:
> Hi,
> On Thu, Sep 30, 2010 at 10:07:05AM +0200, Hynek Hanke wrote:
> > On 30.9.2010 01:01, Halim Sahin wrote:
> > > What do you think about an autorespawn feature for crashed modules?
> > > This would be a great improovment because the new autorespawn feature in
> > > sd is only useful when the whole server crasshes.
> > >
> >
> > Well, autospawn is not designed because of eliminating
> > crashes :) but you are right that it is its side effect and that
> > in a hackish way, it kind of improves the user experience.
>
> Yes :-).
>
> > On the other hand, reloading crashed modules makes quite
> > good sense. Especially in the situation when they have to use
> > third party libraries, which can be quite unstable (as with IBM TTS)
> > and are beyond our control.
>
> ACK.
+yes.
> Stopping resuming after the counter has reached 3 would be possible and
> should work in most situations.
>
> /* detected festival crash */
> If (counter < 3)
> {
> resume("ibmtts");
> counter++;
> else {
> counter = 0;
> set_output_module(NEXT_AVAILABLE_MODULE); // fallback from festival to espeak;
> }
I have to disagree here. A better indicator of a "non-working module"
would be the number of crashes WITHIN a certain time period, like
/* Pseudo code */
if ((number_of_crashes / ten_seconds) > 5); then
kill_module(); replace_by_alternative_module();
else
respawn_module();
endif
This would honour both cases, unstable (proprietary?) modules that
occasionally need an automatic respawn, as well as completely
non-functioning ones that must be removed if non-starting.
It would surely increase the overall stability feeling of sd.
Regards
-Klaus