I've verified that the fix works. Thanks!

Fixed on revision f1a468dbb5dee1426e86382bcc4a5975952a8fdf for 1.10

I've verified the solution through my testing environmen. The new way to generate a unique ID works no matter which kind of collector is being used, and now it is completely independent of the implementation of the toString() method of the CollectionResource interface.

About the Http Collector:

As you can see, the value is not NaN anymore.

Here are some examples for other resource types:

Sorry for getting a little cranky there, but thanks for getting this turned around so quickly! I realize that most OpenNMS opened "issues" are indeed configuration problems, but some of us have filed a half dozen bugs that really were bugs.

Maybe we need some sort of badge or avatar that identifies us "legitimate bug finders" differently than the randoms that open a bug because they just installed the app and can't get notifications working.

Now I saw more clear the problem:

2012-09-11 11:13:42,060 DEBUG [CollectdScheduler-50 Pool-fiber0] CollectionResourceWrapper: getCounterValue: id=org.opennms.netmgt.collectd.HttpCollector$HttpCollectionResource@1f870b40.my_counter, last=null, current=443.16408755547

The ID used to uniquely identify the metrics for each resource on each node inside the cache used to properly handle counter values is wrong for the HttpCollector. In this particular case it should be something like this:

id=node[3].my_counter

or something like that.

I'm going to fix that soon.

Thanks for report this problem.

I could reproduce the problem and now I know where is the problem:

I've added a node with the HTTP service using latest snapshot of 1.10.

I've created a perl script and exposed via Apache on the target node. Here is the script:

It will always generate a number that always increase itself (i.e. a counter).

This the the content of the configuration files:

collectd-configuration.xml:

http-datacollection-config.xml:

threshd-configuration.xml:

thresholds.xml:

Here are the logs:

The relevant lines are the following:

Now, the subsequent collections show that the value is increasing, but getCounterValue still return unknown.

I'm going to reproduce the problem through a JUnit test to see where is the error inside getCounterValue.