On Wed, Feb 9, 2011 at 9:54 AM, Hermann Lauer <
hermann.la...@iwr.uni-heidelberg.de> wrote:
> Hello,
>
> On Wed, Feb 09, 2011 at 08:11:29AM +0100, nap wrote:
> > I think it's an interesting idea. Why not put just an "on_error :
> > 'kill|restart|bypass' state for the module configuration ?
> >
> > If it's in internal, the standard is kill. External can take this
> parameter
> > and manage it if they want.
> >
> > restart mean that if it crash (exception raised on internal, or process
> die
> > on external) it just call quit() of the module (so it close files and co)
> > and then re-init it.
> >
> > By pass should be available only for internal ones (bypass is non sense
> for
> > externals), it means that it will just do as the exception was not here
> (and
> > pray :p ).
> >
> > We can add another property too :
> > * optionnal = 0|1 (0 by default?)
>
> optional, please.
>
Oups yes, 1 as default, the current way of working.
>
> > If it's optionnal, the killing of the module or the no-instanciation will
> > make the whole module in error. If it's the livestatus for example, you
> > don't care if the broker is still alive or not, it's not useless for you
> > (maybe only for logs, so you wait a little before put you in no
> > configuration acceptance).
> >
> > I think we cover all cases with theses 2 parameters, and they are both on
> > the modules, so on the global configuration part, it's more easy to
> manage
> > :)
>
> Sounds good, especialy having the params in the module config.
>
> Generally, when external libraries are included, you will also have things
> like increasing resource utilisation (eating up of memory or
> filedescriptors
> etc.), so an apache like "restart after processing n requests" is
> probably a nice to have.
If we can avoid such things it's better, it's a programming bug to do not
close fds and co ;)
But if the module want to do it, yes, such option can be good :)
>
> This is also needed for inlining checks with python modules (a very good
> thing btw.).
>
Thanks :)
The nrpe module is nearly ok, just need a little clean (the SSL addition for
a asynchronous connexions was fun to debug :p ) :)
>
> Attached is a patch for a few typos I found during code reading.
>
Cool! Thanks, I'm applying it.
Jean
>
> Thanks,
> Hermann
>
> --
> Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres
> Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
> IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224
> Email: hermann.la...@iwr.uni-heidelberg.de
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Shinken-devel mailing list
> Shinken-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>
>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
