Heidi Eckhart wrote:
Dan Smith wrote:
> JG> Is there a mechanism for indications reporting errors, beyond
> JG> CU_DEBUG'ing "help" and hoping to recover?
>
> I would expect that the answer will be that there isn't much that can
> be done. A CU_DEBUG() indicating the issue is certainly required, but
> I'm not sure what else we have.
>
CU_DEBUG() is the providers possibility to report an error. A
mechanism to report a failure in the indication processing itself to
the subscriber of the ComputerSystemModfiedIndication can not be done
via the ComputerSystemModifiedIndication. This indication will only be
thrown, if all went fine. So an indication in general is only
reporting positive results - means, if the filter requirement is
fulfilled, the indication is thrown. To monitor a failing indication
processing an additional indication provider would be necessary. This
one would then handle "please inform me, if something in the
processing of the ComputerSystemModfiedIndication failed". So a client
would need to subscribe 1) to the ComputerSystemModifiedIndication to
get informed of the modification and 2) to the AlertIndication
monitoring the indication processing to get informed of a failing
processing.
Excellent explanation, thanks for that. :) Fortunately it matches
pretty closely to my assumption for how things would work, which is
always nice.
> I tend to think that indications are mostly for convenience and
> optimization, to avoid pinging the providers unnecessarily, in which
> case an error wouldn't be catastrophic. Multiple clients monitoring a
> single provider would use them to notice when the other makes a
> change.
>
I absolutely agree. For now I would say, its more important to have
the ComputerSystemModifiedIndication. But at a later point in time -
an indication provider who reports processing failures could be added
as a feature.
Good, we're all on the same page here. I'll worry about the failure
reporting later (I'll leave the CU_DEBUG calls in for our testing
convenience).
--
-Jay