Re: semi-handled event queue implementation patch

[Martin Pala]

> I think this is a good idea and I'm +1 for adding this patch, but I  
> believe the patch first must include extra functionality to set the  
> queue length and to optionally disable queueing from the monitrc  
> control file, using some kind of [set-statement] e.g. [set event  queue 
> length] or [set event queue timeout] (to drop very old events  off the 
> list) or maybe combine them in a [set event queue...]  statement, to 
> activate the queue  (assuming event queueing is off by  default, which it
> probably should be?).

Very good points :) I will look on it ...

> Since monit can run for a  long time and much can 
> fail, there must be a safety net for not  filling up memory with 
> undelivered events.
>
> This is of course up to you, but 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.

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

The total queue length in the above example is 50.

The user can choose whether to use just memory, just disk or 
combination. When the combination is used, the memory is preferred - as 
soon as it becomes full, the new events are stored to the disk. This 
allows also quick access to the queue head for reprocessing.

It could be also possible to set the slots to 'unlimited' (thus allowing 
the queue to grow up to the physical resources limits)

When monit is stopped or restarted, it can store the event queue to the 
status file and reload it on start.

When the queue becomes full, monit can abort the new semi-handled events 
(maybe the last event added to the queue could describe that the 'event 
queue is full')

> Finally I think it is important to make the distinction that the  
> purpose of such a queue is eventually only for handling undelivered  
> alert events and try to send them again to a (mail) server, not to  
> retry a stop or start at a later time :-)

yes, this is how the patch works currently

Martin