+++ This bug was initially created as a clone of upstream RHQ Project Bug #1015706 +++ Description of problem: Some graphs fail to render, and the following exception is thrown. Caused by: java.lang.IllegalArgumentException: highValue (1.1431E10) is not greater than or equal to value (1.1475666666666666E10). at org.rhq.core.domain.measurement.composite.MeasurementDataNumericHighLowComposite.<init>(MeasurementDataNumericHighLowComposite.java:44) [rhq-core-domain-ejb3.jar:4.9.0] at org.rhq.server.metrics.MetricsServer.createComposites(MetricsServer.java:297) [rhq-server-metrics-4.9.0.jar:4.9.0] at org.rhq.server.metrics.MetricsServer.findDataForResource(MetricsServer.java:171) [rhq-server-metrics-4.9.0.jar:4.9.0] Version-Release number of selected component (if applicable): 4.9 How reproducible: Depending on the dataset, this can happen fairly frequently. The panel fails to render at all. It would be nice if the server caught the exception, or fixed the data so it didn't fail to show anything at all. I'm guessing the threshold is basically something that doesn't work for large numbers. if (highValue < value && Math.abs(highValue - value) > THRESHOLD) { ^^^ might want to use division not subtraction here. --- Additional comment from Elias Ross on 2013-10-04 17:28:08 EDT --- Even if you fix the threshold, I'd be highly annoyed if my graph just failed to come up. Why not just have 'highValue = value' if there is a rendering issue.
This bug started showing up for us after upgrading from 3.1.2 to 3.2.0.
The problem was a bug in a method that calculates aggregate metrics. It could produce an incorrect max because of if else statement that should have been an if. The code looked like, if (metric.getMin() < min) { min = metric.getMin(); } else if (metric.getMax() > max) { max = metric.getMax(); } This bug only effects 6 hr and 24 hr metrics. It manifests itself for 6 hour data for example when both the min and max of the 1 hour data being aggregated fall on the same 1 hour aggregate metric. I have pushed changes to the release branch that do a couple things. First, the above code is fixed. Secondly, we check for invalid max values. If we come across one, we log a warning and "adjust" the metric. We set the max to the average and and persist the updated value. release/jon3.2.x commit hashes: d8622d88ea4 fc97c223796
One of the commit hashes in comment 4 is incorrect. The two commit hashes on the release/jon3.2.x branch are, f7c0b3550615 fc97c22379
Via product triage, determined that this bug is to be included for DR01 target milestone.
Moving to ON_QA as available for test in latest cumulative patch build(DR01): http://jon01.mw.lab.eng.bos.redhat.com:8042/dist/release/jon/3.2.2.GA/5-29-2014/
This has been verified and released in Red Hat JBoss Operations Network 3.2 Update 02 (3.2.2) available from the Red Hat Customer Portal[1]. [1]: https://access.redhat.com/jbossnetwork/restricted/softwareDetail.html?softwareId=31783