+++ This bug was initially created as a clone of Bug #1034991 +++ Description of problem: This is one that @ahovsepy and @skondkar brought up with the summary metric last value sometimes not matching the value in the graphs. Version-Release number of selected component (if applicable): RHQ 4.1.0 and JON 3.2.0 ER7 How reproducible: Depends on time range. Steps to Reproduce: 1. Navigate to the monitor metrics tab 2. Navigate to the EAP RHQ Server 3. Observer the summary metrics value for 'Maximum Request Time' 4. click on the chart link for 'Maximum Request Time' and hover over last bar. Observer the Avg. value. Actual results: Depending on various time ranges these last values may or may not match. Expected results: The summary metric last value and chart last value (avg value on aggregate bar)should match. --- Additional comment from Mike Thompson on 2013-11-26 15:22:08 EST --- I have changed the code to use exactly the same date range and metric api. It was possible to use different metrics apis for the different time range types. I eliminated the variation, so that the summary last values are pulling from the same single metrics api as the charts. Committed to master: a532e90
Cloning for JON 3.2.0 (CR01) as this needs to be taken as part of BZ 1034852.
Committed to release/jon3.2.x as: 393d350
Moving to ON_QA for testing in latest(CR1) brew build.
Created attachment 832548 [details] metric_dummary_chart
Created attachment 832560 [details] free-space-chart-summary-values
re-assigned issue is still visible in CR1 - screen-shots attached
The charts use different precision which end up in slightly different values displayed - rounding 2.1G and 1.9G to GB boundaries both result in 2 G -- this is probably not nice, but it is not way off.
The original issue here is fixed and a new issue was found. This bug was referring to the summary metrics not being refreshed when the time range was changed and this was a bug and it fixed with this commit. Now, the issue is with round/precision through javascript instead of java. This kind of sophisticated rounding requires knowledge of units (Bytes, seconds) and groupings of precision(Terabyte, Gigabyte, Kilobyte, byte). On the summary metrics detail graph, the averages box at the right and the hovers has rounding/precision errors. That should be the new BZ. Much less severe than the blocker that was fixed.
I fixed the significant/digits precision issue with graph legend. committed to master: ec67bac
per bz triage ... closing this as VERIFIED CLOSED cURRENT RELEASE and opening a new bug for comment #9 (i will document new BZ in comment #15)
new BZ to capture loose end in comment #9 https://bugzilla.redhat.com/show_bug.cgi?id=1051583