Bug 778489 (SOA-957) - wrong "Low" value in JBoss ESB Statistics metrics
Summary: wrong "Low" value in JBoss ESB Statistics metrics
Keywords:
Status: CLOSED NEXTRELEASE
Alias: SOA-957
Product: JBoss Enterprise SOA Platform 4
Classification: JBoss
Component: Documentation, Monitoring and Management
Version: 4.3 CR1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.3 GA
Assignee: Dana Mison
QA Contact:
URL: http://jira.jboss.org/jira/browse/SOA...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-20 08:07 UTC by Jaroslaw Kijanowski
Modified: 2009-01-16 16:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-16 16:11:43 UTC
Type: Bug


Attachments (Terms of Use)
low.png (88.77 KB, image/png)
2008-10-20 08:08 UTC, Jaroslaw Kijanowski
no flags Details
12.png (87.96 KB, image/png)
2008-10-20 08:08 UTC, Jaroslaw Kijanowski
no flags Details
120.png (87.70 KB, image/png)
2008-10-20 08:08 UTC, Jaroslaw Kijanowski
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker SOA-957 0 Major Closed wrong "Low" value in JBoss ESB Statistics metrics 2013-09-23 08:48:34 UTC

Description Jaroslaw Kijanowski 2008-10-20 08:07:34 UTC
Affects: Documentation (Ref Guide, User Guide, etc.)
Date of First Response: 2008-10-20 05:08:28
project_key: SOA

I have run tests for ~3 days, extended the metric display range to 12 days and what I would expect is that the "Low" value of "Message Count (Total)" and "Message Count (Successful)" is zero - this is the lowest value for the last 12 days, isn't it? See low.png for details.

Moreover the Bytes Processed Low value differs when I switch the Display Time Range from 12 days to 120days. See 12.png and 120.png. That also shouldn't happen.

Tom, since the Low value is not taken from an MBean but calculated, is this a JON issue or something on the plugin side?

Comment 1 Jaroslaw Kijanowski 2008-10-20 08:08:01 UTC
Attachment: Added: low.png
Attachment: Added: 12.png
Attachment: Added: 120.png


Comment 2 Kevin Conner 2008-10-20 09:08:28 UTC
Presumably the lowest value would be the value of the count from the first query to the server, whatever that happens to be.

Comment 3 Jaroslaw Kijanowski 2008-10-20 09:34:08 UTC
yep, thought about that too, but the default collection interval is 10 minutes, so this would mean that after the first ten minutes, since I've added the SOA-P to the inventory, 2669 messages has been sent. A little bit strange if you consider that I've imported it immediately. Anyway I try to reproduce this with a fresh installation later. I *think* the value was "6" at the very beginning, which would make sense.

Comment 4 Kevin Conner 2008-10-20 09:43:17 UTC
I'm not sure how JON would handle this but I would have expected it to make a query as soon as you had inventoried it.  It may be that it does defer the collection, as you say.

In any case it is the value in the ESB server that is relevant as it starts counting as soon as the server is running and will always increase, unless the counters are reset or wrap.

Comment 5 tcunning 2008-10-20 13:02:34 UTC
As Kevin says, the lowest value of the count would be the first query to the server.      If the SOA-P server was started in advance of the JON agent, then it may not be 0.  

The bytes processed differing is strange - that may be a symptom of http://jira.rhq-project.org/browse/RHQ-963, you may want to file a JBNADM bug against that.      Without any JMX evidence, there's nothing here to suggest that this is a bug in the plugin.

Comment 6 Len DiMaggio 2008-10-20 15:20:19 UTC
Question:  "the value in the ESB server that is relevant as it starts counting as soon as the server is running and will always increase, unless the counters are reset or wrap"

So - for this value ^ - we should be able to always check the value in the legacy ESB Mgmt console, right?



Comment 7 Jaroslaw Kijanowski 2008-10-20 18:20:39 UTC
(07:51:42 PM) mazz: ok, I think I get it... if you provide a timeframe LONGER than what our raw measurement tables contain, we query the compressed tables
(07:51:55 PM) mazz: and the compressed tables don't have all the raw data points
(07:52:18 PM) mazz: if you look at the graphs for the 120 days, its got a single data point, at the high number
(07:52:39 PM) mazz: hence why the "low" shows you the high number - because currently, there is only a single data point in the compressed table
(07:53:38 PM) mazz: I think this is "working as expected".  I think as per design we are allowed to lose detailed information for old data
(07:53:57 PM) ghinkle: correct
(07:54:01 PM) joseph: jarek - this is by design.  if you look at course grained time periods, the data gets less and less accurate.  don't look for perfection at 120 days out, look for it at small scales.
(07:54:37 PM) mazz: this makes for a good FAQ :) or documented somewhere
(07:54:57 PM) mazz: explain raw measurement data, compressed measurement data and how you lose accuracy as the data ages
(07:56:34 PM) mazz: actually, "lose accuracy" isn't the correct term
(07:56:41 PM) mazz: the data is accurate for what it represents
(07:57:06 PM) mazz: you just lose "fine-grained" data - in its place you get coarse-grained compressed data

Comment 8 Len DiMaggio 2008-10-20 18:39:35 UTC
Just to confirm - this is a "vanilla" JON issue and is not specific to the ESB plugin, correct?

If this is the case, the explanation should be in the JON docs - but - it will affect SOA-P users, so we should include this JIRA in the list of open bugs in 4.3 release notes.



Comment 9 Len DiMaggio 2008-10-20 18:40:34 UTC
Assigned to Darrin, set documentation component, selected documentation 'affects' flag.


Comment 10 Len DiMaggio 2008-10-20 18:40:34 UTC
Affects: Added: [Documentation (Ref Guide, User Guide, etc.)]


Comment 11 Jaroslaw Kijanowski 2008-10-20 19:27:29 UTC
Related RHQ jira is http://jira.rhq-project.org/browse/RHQ-999

Comment 12 Kevin Conner 2008-10-21 08:13:32 UTC
"we should be able to always check the value in the legacy ESB Mgmt console, right? "

If you check the MBean before/after the first poll from JON then I would expect the minimum value reported to lie somewhere between those values.

Comment 13 Dana Mison 2008-10-27 11:00:37 UTC
note added

Comment 14 Len DiMaggio 2009-01-16 16:11:43 UTC
Closing - it's listed in the 4.3 GA release notes and here:  http://jira.rhq-project.org/browse/RHQ-999


Note You need to log in before you can comment on or make changes to this bug.