| Summary: | [Platform Plug-in] FileSystemComponent returns invalid diskQueue metric due to calling refresh method of FileSystemInfo twice when gathering metrics | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Other] RHQ Project | Reporter: | Larry O'Leary <loleary> | ||||
| Component: | Plugins | Assignee: | Charles Crouch <ccrouch> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike Foley <mfoley> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 4.2 | CC: | ccrouch, hbrock, hrupp, lkrejci, spinder | ||||
| Target Milestone: | --- | ||||||
| Target Release: | RHQ 4.3.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | 4.3 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 769936 783879 (view as bug list) | Environment: | |||||
| Last Closed: | 2013-09-01 10:16:23 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Bug Depends On: | |||||||
| Bug Blocks: | 753904, 783879 | ||||||
| Attachments: |
|
||||||
|
Description
Larry O'Leary
2011-11-10 22:33:14 UTC
Nice find. Fixed in master - commit 68be8c6: http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commitdiff;h=68be8c6 Upon further investigation the multiple executions actually result in invalid data coming back from the native library. The statistics that are gathered are time based with a time resolution of 1 second and some of the values are calculated based on the last "gather" time. If the refresh method is called in succession with a second or less between, the result is disk stats being calculated with: 0.0 / 0 = NaN > 0.0 / 0 = Infinity The result depends on the execution time. Disk Queue test with delay of 0 returned 100 NaN results and 0 infinity results out of a total tests of 100 Disk Queue test with delay of 1 returned 100 NaN results and 0 infinity results out of a total tests of 100 Disk Queue test with delay of 5 returned 68 NaN results and 32 infinity results out of a total tests of 100 Disk Queue test with delay of 10 returned 70 NaN results and 29 infinity results out of a total tests of 100 Disk Queue test with delay of 50 returned 64 NaN results and 31 infinity results out of a total tests of 100 Disk Queue test with delay of 100 returned 51 NaN results and 39 infinity results out of a total tests of 100 Disk Queue test with delay of 500 returned 34 NaN results and 16 infinity results out of a total tests of 100 Disk Queue test with delay of 1000 returned 0 NaN results and 0 infinity results out of a total tests of 100 Disk Queue test with delay of 1001 returned 0 NaN results and 0 infinity results out of a total tests of 100 Disk Queue test with delay of 1010 returned 0 NaN results and 0 infinity results out of a total tests of 100 Disk Queue test with delay of 1050 returned 0 NaN results and 0 infinity results out of a total tests of 100 Disk Queue test with delay of 1100 returned 0 NaN results and 0 infinity results out of a total tests of 100 Disk Queue test with delay of 1500 returned 0 NaN results and 0 infinity results out of a total tests of 100 Disk Queue test with delay of 2000 returned 0 NaN results and 0 infinity results out of a total tests of 100 Committed to release-3.0.1 as 96b03ecc9c77bd80e72792fd996b3a0ad6592229 - http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commitdiff;h=96b03ecc9c77bd80e72792fd996b3a0ad6592229 Larry, would you be able to provide repro steps for this issue? 1. From a Linux Platform resource, expand and select File System -> /boot 2. Select the Monitor > Tables sub-tab 3. The Last value for Disk Queue should contain a number Actual Result: <no value / i.e. it is blank> Expected Result: 0 or a positive number Please note that by default this metric is collected once every 20 minutes. So, if you are tested a new installation, it is best to drop the collection schedule for this metric to 1 minute so you do not have as long to wait. Available to test in 3.0.1.GA RC2 available here: https://brewweb.devel.redhat.com//buildinfo?buildID=197202 Created attachment 559375 [details]
image of verification (fail to verify)
image to document my observations. fail to verify at step #3 in repro steps.
fail to verify. image documenting failure of repro steps at step #3. i don't see disk queue Setting back to ON-QA for the master branch and RHQ4.3 based on https://bugzilla.redhat.com/show_bug.cgi?id=783879#c8 Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since. |