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

[Jan-Henrik Haukeland]

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

-- 
Jan-Henrik Haukeland