Nagios Support Forum

In message ,
Andreas Ericsson writes:
>On 08/08/2012 09:40 PM, [email protected] wrote:
>> [rouilj 8/6]
>> [rouilj 8/6] So add a field that is a pointer to a nagios maintained data
>> [rouilj 8/6] store for each object. Where each object in the datastore is
>a
>> [rouilj 8/6] key/value (blob pointer) pair. "adding items to the object"
>> [rouilj 8/6] wasn't meant as add a new field. More along the lines of add
>a
>> [rouilj 8/6] new item to a linked list in the object.
>> [rouilj 8/6]
>> [Andreas 8/7] Why on earth would you prefer O(n) complexity over O(1)?
>> [Andreas 8/7] Do you realize that you're requesting something that's
>> [Andreas 8/7] both slower and more complex than what I proposed?
>>
>> Arrays are fixed length. What do you expect to use for the size
>> of the array? I agree being able to do an address lookup at
>>
>> array_start + n*(sizeof pointer)
>>
>> is a win, but it's also a good way to end up wasting a lot of
>> space by oversizing the array at compile time to support an
>> undeterminable number of brokers/plugins/modules.
>
>Why on earth would you want to do that at compile time? You can
>just
>
> ary = malloc(sched_info.services * sizeof(whatever));
>
>at runtime and waste zero memory instead. We don't have to put
>everything on the stack.

You said about the object being a fixed size at compile time, so I
made the leap that you were expecting a statically sized object. I
need more coffee.

Is it a requirement that a broker must not add or remove objects from
nagios while it's running? I am guessing that must be a rule otherwise
you can't know how many bytes to malloc.

>> After all every
>> object (host, service) will need this array. An alternative is
>> to take some time to traverse a linked list (or binary tree, hash
>> table ....) and reducing the amount of memory needed.
>>
>
>Linked list require more memory per stored object since they also
>must have pointers to the next item in the array.
>
>> Now if you are taking about mallocing the array and allowing the
>> number of elements in the array to be set in the config file
>> that's something different, but I saw no indication of that.
>>
>
>Not config file. I imagine 99.9999% of the usecases will be to
>support arrays that are of exactly the same size as the number of
>some type of objects.

Well in the few use cases I received data on people only needed
advanced correlation on 10% of the services, but the wasted memory for
a pointer (as opposed to a larger data item) isn't that significant,
and could certainly fall into the .0001% of use cases.

>> Ideally to save on memory you would want a configuation setting
>> for each object type, but a single setting for all objects would
>> probably work without too much waste.
>
>What on earth do you want to store??

Given your realization below that I was attaching the data to the
nagios object, I guess your question is answered.

>> [rouilj 8/3] Custom variables help a little bit but introduce the need to
>> [rouilj 8/3] parse the value on every event which is not acceptable. The
>> [rouilj 8/3] value should be parsed once into a quickly accessible form
>> [rouilj 8/3] (e.g. bitfield) and carried around with the object.
>> [rouilj 8/3]
>> [andreas 8/3] Well, no. You might want to add things other than flags in
>> [andreas 8/3] such variables and you may well have several modules at once
>> [andreas 8/3] competing for the dubious honor of putting extra junk into
>> [andreas 8/3] objects.

I assume there will be some mechanisim to register the module with the
config file parser.

>> [rouilj 8/3] Are there any plans to add something like:
>> [rouilj 8/3]
>> [rouilj 8/3] add_new_custom_variable_property(SERVICE_OBJECT, "_ec_acti
>ve_action",
>>> \
>> [rouilj 8/3] func_parse_ec_active_action);
>> [rouilj 8/3][...]
>> [rouilj 8/3] int add_property_value(*service_object, "_ec_active_action
>", void * v
>>> alu
>>> [rouilj 8/6] e)
>> [rouilj 8/3]
>> [rouilj 8/3] void * get_property(*service_object, "_ec_active_action");
>> [rouilj 8/3]
>> [rouilj 8/

...[email truncated]...


This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]