Re: semi-handled event queue implementation patch

[Jan-Henrik Haukeland]

On 7. okt. 2005, at 11.46, Martin Pala wrote:

> > .. instead of using memory directly it  can be an idea to use the  
> > monit state file and read/write undelivered  events from this  
> > file? Just a thought.
>
> I though about it as well. Both queue backends (disk or memory) may  
> become full independently of each other. The disk has additional  
> advantage over memory, that it can hold the persistent queue, which  
> will be kept across monit restarts.
>
> Maybe we can do the queue backend little bit adaptive - for example  
> it could be possible to set the total event queue (i.e. maximum)  
> and the memory backend part as well.

It is necessary to store undelivered alert events in memory, but I  
suggest that this should only be used as a cache and be thrown away  
at the end of a poll-cycle. The actual queue and logic around  
resending events should, I believe, be centered around the state file  
only. As you said, having persistency is pretty important for this  
effort, otherwise all queued events will simply vaporize if monit  
crashes or if monit is restarted.

Only a few changes should be required from your original patch. As  
before, events are stored in memory if delivery fails in  
Run.eventlist. The change is that these events are then stored in the  
state file at the end of a cycle. Upon successful storage  
Run.eventlist is freed to make memory available again. And because  
the eventlist will not grow and are freed, it should not be necessary  
to limit the size of the queue via a [set .. memory slots]. The list  
will not use much memory (if any) in one cycle. Having a [set .. disk  
slots] limit is useful. This limit can be made optional and if not  
set, available disk space are used.

The bottom line is that I think that it can be easier to choose one  
solution, preferably the file storage, instead of having logic to  
handle a hybrid event queue, both in memory and in file.

Below I have tried to sketch some ideas in pseudo code. These are  
*just suggestions* and not necessarily well thought out nor something  
you should use.

At the end of validate() perform queue handling as sketched:

 /* Read number of stored events from monit state file */
 int nevents= fread(statefile);

 /* Try to resend stored events */
 Event_T event;
 for(i= nevents; (i < nevents && event= fread(statefile)); i++) {
     resend event;
     if(success) {
         remove event from state-file;
     }
 }

 /* Finally, just store the cached eventlist in the state file */
 int new_size= Run.eventlist.size + nevents;
 write size to monit state file;
 skip to end of state file;
 foreach(event in Run.eventlist) {
     write event to the state file
 }

The file handling can be complicated since the whole file must *not*  
be read up into memory. If you think I can help with the coding,  
please let me know.


> --8<--
>  set event queue
>    memory slots 10
>    disk slots   40
>    [enable|disable]
> --8<--

Looks fine! But as noted above "memory slots" should not be necessary  
and the default should be disabled. I.e. the queue is not used unless  
the user explicit write [set event queue .. enabled] in monitrc. Agree?

--
Jan-Henrik Haukeland
Mobil +47 97141255