Please don't top-post.
Julien Mathis wrote:
> Hi,
>
> We have developped a debuging brocker and we have this two consecutive
> events in debug :
>
The figures you posted are really just crap to me as I have no idea what
the different figures are suppose to mean.
A hook such as the one below would let you debug this
properly:
int service_hook(int callback, void *data)
{
nebstruct_service_check_data *ds;
ds = (nebstruct_service_check_data *)data;
static char *host_name = NULL;
static char *service_description = NULL;
if (ds->type != NEBTYPE_SERVICE_CHECK_PROCESSED) {
return 0;
}
if (host_name && !strcmp(host_name, ds->host_name) &&
service_description &&
!strcmp(service_description, ds->service_description))
{
fprintf(stderr, "Completed check processed twice sequentially\n");
}
host_name = strdup(ds->host_name);
service_description = strdup(ds->service_description);
return do_service_hook_stuff(ds);
}
Yes, I know it leaks memory, but I really don't care about that. You're
not supposed to run it any length of time anyways.
Note that this condition can happen validly if the same service check for
some reason is executed twice without a different service-check being run
in between. I expect that wouldn't happen all that often, but it *could*
happen.
>
> => last check, execution time, latency and next check are the same on each
> update. If they are one call before and one call after, this data must be
> differents.
>
last_check, next_check and latency should definitely not be different
on the two calls to the broker module. execution time should (well,
most likely will be anyways), but I have strong doubts that you're
using the eventbroker API properly. I've written several modules myself
(six or seven) and never found any problems in how callbacks are generated.
> I'm ok that DNX need this event. But the event
> (NEBCALLBACK_SERVICE_CHECK_DATA I think) need to be different. Why not
> creating NEBCALLBACK_SERVICE_START_CHECK event ?
>
Because of the NEBTYPE_SERVICE_CHECK_PROCESSED. Perhaps it would be
better to create new nebcallbacks, but that would break the API so
it won't happen until Nagios 4 at the very earliest. Besides, it's
truly a micro-optimization. 11 CPU instructions are wasted on 386
architectures when we make a function call with two parameters that
return immediately after checking one integral condition. There are
bigger fish to fry when talking optimization, and those bigger fish
do not involve forcing module writers to support multiple broker
API's.
--
Andreas Ericsson [email protected]
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Register now for Nordic Meet on Nagios, June 3-4 in Stockholm
http://nordicmeetonnagios.op5.org/
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]