#51 CMPI-BASE: Indication Provider delivers only first occurence

[Heidi Eckhart]

The check() function of
cmpiOSBase_OperatingSystemProvider.c to monitor the OS
OperationalStatus does not behave as expected by the
indication_helper library. The inidcation_helper
library expects, that the value of the
OperationalStatus is returned by the check() function -
based on this expectation, the indication_helper lib
delivers an indication, each time, the current value
compared to the previous value has changed. The check()
function instead indicates by 0 that nothing has
happened and 1 that an indication should be thrown.
This leads to the problem, that with the current
implementation of the check() function, only the first
indication is delivered.

[Viktor Mihajlovski]

Logged In: YES
user_id=1198711

I reopen this as I am not yet fully understanding whether
this is the right way to handle. Can somebody (Heidi,
Konrad) explain what happens, if we have multiple properties
that can contribute to an indication? Do we have to register
one check function per property? If yes, what is the impact
to performance? Is the number of delivered indications what
one would expect? If no, what value would the check function
return?
BTW: I have assigned Konrad in order to make him aware of this.

[Konrad Rzeszutek]

Logged In: YES
user_id=852838

This a bit complex issue and from talking to Heidi I think
we came to an agreement. I will provide a summary and Heidi,
please comment if I missed something or misunderstood.

1). Konrad will document how the "monitor" functions are
checked.
" The polling function (defined as the <li>check</li) will
be pulled based on the timer specified. The value passed in
to the parameter will be checked against the previous value
that was returned earlier. If there is a change, the library
will immediately call all of the property functions, create
an instance and attempt to deliever it (if the evaluation of
the instance against the indication filter is true).

This detection mechanism is also comonly called 'edge level
detection' or 'trigger detection'. It means that the CIM
Listener will not be bombarded with indications but only
when state changes.

For example, if the monitor function was passing these
values through its parameter:
0, 1,1,1,0,

There would only be two indications sent (of course, pending
the evaluation agains the indication filter).

Caveat: On the first call to the monitor function, the
previous state is not known. The library considers this
first call as the seed call and does not deliever the
instance. Please make sure to structure your code
accordingly and have a check for the first call.

Note: The function prototype for the monitor function is the
same as for retrieving the property values. This means you
can use the same function for both purposes. For example,
assume you have a property named 'OperationStatus' that
returns two values: 2 (OK) or 4 (Stressed). The value of
this property could be the driver for triggering the
indication. Thus you could do this:

ind_reg_pollfnc("CIM_ModifyInstance", "OperationalStatus",
check_os, 10);
ind_set_property_f("root/cimv2","CIM_ModifyInstance","OperationalInstance",
check_os);

2). Heidi will re-strucutre her provider to use the above
mentioned logic instead of relaying on having the value
checked against 0.

[Viktor Mihajlovski]

Logged In: YES
user_id=1198711

I have verified that it works with Pegasus 2.5 with
http://cvs.rdg.opengroup.org/bugzilla/show_bug.cgi?id=3734
fixed and sblim-cmpi-base 1.5.2.