Re: monit http thread responsiveness patch

[Jan-Henrik Haukeland]

On 28. jun. 2006, at 00.24, Martin Pala wrote:

> Jan-Henrik Haukeland wrote:
> > On 27. jun. 2006, at 15.36, Martin Pala wrote:
> > > Description of the patch:
> > >
> > > When some action is requested via http, the http thread just  
> > > sets  the "doaction" task on the given service thread and wakes  
> > > up the  main thread. The main thread then performs normal testing  
> > > cycle and  when it founds the doaction flag on any service, it  
> > > performs the  requested action.
> >  From the patch
> > +++ validate.c    27 Jun 2006 11:38:58 -0000
> > +      if(s->doaction != ACTION_IGNORE) {
> > +        control_service(s->name, s->doaction);
> > +        s->doaction = ACTION_IGNORE;
> > +      } else if(s->monitor && !check_skip(s) && !check_timeout(s)) {
> > I think it may be better to run a new for-loop first and only  
> > check  and act on the doaction flag or merge the if-else. In the  
> > code above,  services with this flag set is excluded from the  
> > standard test (in  the else part), which probably is not what we  
> > want.
>
> Good topic :) I'll try to explain the cause - maybe i'm wrong:
>
> It was based on the assumption, that when the action is scheduled  
> by the http thread (such as stop/restart/start) it has higher  
> precedence for particular service then the monitoring and it is not  
> needed to check the service in the same cycle.
> For example, when the service is to be restarted, it will be  
> initializing after the restart and when we will try monitor it in  
> the same cycle, it may not be fully initialized yet and monit can  
> produce false alarms, thus i think it is better to perform the  
> restart and postpone the monitoring on the next cycle.

Ah yes, initializing. For restart and start (after stop) you need to  
wait one poll cycle anyway, otherwise we must add more complicated  
code and test if and when a service is ready to be tested. I see your  
point and agree that it is easier and simpler to postpone the service  
check until the next cycle. I don't remember and don't bother to  
check the code now, but this is probably the case also when turning  
monitoring on after unmonitoring?

Ok, my unconditional +1 for your patch then :) Good work!

--
Jan-Henrik Haukeland
Mobil +47 97141255