Re: PLAN: DONE [Please read]. Now your turn :-)

[Rory Toma]

I'm coming up on some time, so...

Once everything gets settled down, I'll make sure and fix (if need be)

freebsd
openbsd
netbsd
macosx

plus linux and solaris if they need any

I should be able to get into this next week.

On Wed, 2003-07-02 at 11:59, Jan-Henrik Haukeland wrote:
> I have now refactored and reimplemented the Event machinery for monit.
> 
> If you are a committer, please read this mail since things have
> changed :-)
> 
> 
> I have added a new class called event.c/event.h which implements the
> event handling machinery I outlined in a previous mail. You should
> examine this class and try to understand how event handling is done.
> 
> Here is a brief description of the changes:
> 
> 
> 1) All the alert_xxx methods are removed.
> 
> 2) do_start/do_restart/do_stop is removed from validate.c, simplified
>    and moved into event.c as event handlers for start/restart/stop
>    events.
> 
> 3) There is now a single unified api for posting events. The method
>    you should use is Event_post(..) see event.c for details.
> 
> 4) Event handling is conducted in the local method handle_event in
>    event.c. Here, all action events i.e. start/restart/stop events are
>    handled. Alert events are also handled in this method and later
>    when implemented, exec events will be handled there as well. As you
>    can see from the handle_event method the logic is as follows: When
>    an event is recieved the event is dropped down through the various
>    event handlers which will handle the event (or not). 
> 
> 5) A new start event is added to truly distinguish between start and
>    restart events. If a Service start/stop/restart should fail for
>    some reason the event is changed to a failed event and the user is
>    notified that the action failed. This was not the case before and
>    monit should now be much more consistent in reporting.
> 
> 6) The event handling architecture in monit is now a true event
>    handling system and the design should make it easy to include new
>    event handlers in a consistent and in a logic way. If necessary it
>    is also possible to do the call to handle_event in a new thread to
>    make the event handling non-sequential and more responsive.
> 
> 
> TODO
> 
> Christan and Martin, I hope that you can refactor the code in
> validate.c as I mentioned in the previous mail on this topic, so that
> all the code in the switch/case statement is moved into it's own
> function. 
> 
>    case TASK_PROCESS   <- Christian
>    case TASK_DEVICE    <- Martin
>    case TASK_FILE      <- Marin
>    case TASK_DIRECTORY <- Martin
> 
> Agree? 
> 
> 
> 
> Jan-Henrik Haukeland <address@hidden> writes:
> 
> > Okay to summarize the latest event discussion here is the PLAN. I will
> > start on this today and hopefully have it ready later this
> > evening/night.  This work is necessary to prepare monit for Martin's
> > method language changes.
> >
> > The plan is to replace the current alert_xxx with a true event system
> > but do this as gentle as possible and avoid changing to much of the
> > code. Most notably the change will simply replace alert_xxx with a
> > post_event() method in validate.c. After I have done this I hope that
> > Christian and Martin can refactor all code in validate.c contained in
> > the
> >
> >    case TASK_PROCESS
> >    case TASK_DEVICE
> >    case TASK_FILE
> >    case TASK_DIRECTORY
> >
> > into the following functions:
> >
> >   check_processes(); // Including mem/cpu/children/ and if process is 
> > running
> >   check_device()
> >   check_file();
> >   check_directory();
> >
> > with the new event system this should be not to much work.
> >
> > THE GOAL is that do_validate will look like this when we are finnished:
> >
> > static void do_validate(..) {
> >
> >   // initialization
> >   ...
> >   check_processes(); // Including mem/cpu/children/ and if process is 
> > running
> >   check_device()
> >   check_file();
> >   check_directory();
> >   
> > }
> >
> >
> >
> > What I will do:
> >
> > 1) Create an Event_T object looking like this
> >     typedef struct myevent {
> >             int id; // The event type [DO_STOP, DO_TIMEOUT ...]
> >             Service_T source; // The Service the event occured on
> >             char message[STRLEN]; // Optional descripton of the event
> >     } Event_T;
> >
> > 2) Remove Alert_T and replace Alert_T with: long events; where events
> >    is a bit-mapped flag containing events. This means that Mail_T will
> >    look like this:
> >    
> >    /** Defines a mailinglist object */
> >    typedef struct mymail {
> >            char *to;           /**< Mail address for alert notification */
> >            char *from;                       /**< The mail from address */
> >            char *subject;                         /**< The mail subject */
> >            char *message;                         /**< The mail message */
> >            char *opt_message;   /**< An optional message used in alerts */
> >    NEW-->  long events;     /**< Events triggering this mail to be sent */
> >           /** For internal use */
> >           struct mymail *next;              /**< next recipient in chain */
> >    } *Mail_T;
> >
> > 3) Create the following events and removing DO_XXX:
> >
> >    #define START_EVENT     1
> >    #define STOP_EVENT      2
> >    #define RESTART_EVENT   4
> >    #define CHECKSUM_EVENT  8
> >    #define RESOURCE_EVENT  16
> >    #define TIMEOUT_EVENT   32
> >    #define FAILED_EVENT    64
> >    #define TIMESTAMP_EVENT 128
> >
> >
> >    Setting an event in e.g. Mail_T will look like this
> >
> >     Mail_T m; ..
> >   
> >     m->events |= START_EVENT;
> >     m->events |= STOP_EVENT;
> >
> >     If no events is set, m->events has the value 0
> >
> >     Checking for events will look like this:
> >
> >     if(m->events & START_EVENT) { do start stuff }
> >     if(m->events & STOP_EVENT)  { do stop stuff }
> >
> >
> > 4)  Create a new module called event.c containing at least two functions.
> >
> >     /**
> >      * Post an event to the event handler
> >      * @param source The Service the event occured on
> >      * @param id The event type
> >      * @param  s Optional message describing the event
> >      */
> >     void post_event(Service_T source, long id, char s, ...);
> >
> >     The post_event function will call handle_event
> >
> >     /**
> >      * Handle the posted event
> >      * @param event The event to handle
> >      * @return TRUE if the event was handled otherwise FALSE
> >     static int handle_event(Event_T event);
> >
> >
> > 5) Please do not check-in anything into CVS until this is ready.
> >
> > -- 
> > Jan-Henrik Haukeland
> >
> >
> > _______________________________________________
> > monit-dev mailing list
> > address@hidden
> > http://mail.nongnu.org/mailman/listinfo/monit-dev
-- 
Rory Toma               address@hidden
VP of Run Level 9       http://www.trs80.net
Digeo Digital           http://www.digeo.com

signature.asc
Description: This is a digitally signed message part