event broker -> SQL questions

[Ben]

Okay, that's pretty much the conclusion I was coming to. It leaves me 
confused about the design goals of status events vs. service events, 
but in any case, It looks like I just might have to deal with duplicate 
events in my module.

Can I at least be guaranteed that ALL the status events for the current 
state will be delivered before ANY of the status events for the next 
state? I'm not seeing much threading in nagios other than to handle IO 
and deal with checks, so I imagine the answer is "yes", but maybe 
somebody has a ready counter example?

On Oct 20, 2004, at 7:31 PM, Ethan Galstad wrote:

> Back to your question then.  The status events have little to do with
> actual checks.  Yes, they do occur before and after checks have
> occurred, but they're not directly tied to them.  Anytime *any* of
> the variables/attributes of a host or service are changed, the status
> events get generated.  This means status events will get triggered in
> the following situations (this is not inclusive):
>
> 	- A check gets rescheduled
> 	- A check gets initiated
> 	- Check results get processed
> 	- Host/service attributes get changed by external commands
> 	- Attributes get changed by internal logic (i.e. flap detection)
> 	- etc.
>
>
>
> On 15 Oct 2004 at 17:00, Ben wrote:
>>
>>
>> In base/checks.c, reap_service_checks calls schedule_service_check
>> before it generates the SERVICE_STATUS event. schedule_service_check
>> also generates a SERVICE_STATUS event. It seems like this might not be
>> right.....



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl