If a threshold configuration contains invalid data from evaluators point of view a silent exception is thrown.

Suppose that we need to define a relative change threshold, and we include the following definition on thresholds.xml:

<expression description="discarded packets" type="relativeChange" ds-type="if" value="1.0" rearm="0.0" trigger="1" ds-label="ifDescr" filterOperator="or" expression="ifInDiscards + ifOutDiscards"/>

After reloading the configuration, it is noticed that the changes weren't applied and the user was never notified about why that happened.

The reason is because the class named ThresholdEvaluatorStateRelativeChange (which lives inside ThresholdEvaluatorRelativeChange), has a validation rule that throws an exception if the value is equals to 1.0. That's because this value doesn't make sense for relative change threshold.

In the logs, there are some warning messages related with this issue, for example:

2011-12-13 11:29:19,859 ERROR [CollectdScheduler-600 Pool-fiber0] CollectorThresholdingSet: initialize: Can't process threshold group dms-over-vpn
java.lang.IllegalArgumentException: threshold must not be unity (1.0)

Or,

2011-12-13 17:29:56,499 WARN [OpenNMS.Collectd] EventIpcManagerDefaultImpl: run: an unexpected error occured during ListenerThread OpenNMS.Collectd run: java.lang.IllegalArgumentException: threshold must not be unity (1.0)

So, the idea is that Collectd should track down all the reloading process and trigger an event reloadDaemonConfigFailed if something went wrong, in order to notify the user about the error in the configuration file.