parseData returns int which is too small to hold large values like 4Gb heap sizes

[GoogleCodeExporter]

What steps will reproduce the problem?
1. java -cp jmxquery.jar -U service:jmx:rmi:///jndi/rmi://app8:9997/jmxrmi
-O java.lang:type=Memory -A HeapMemoryUsage -K used -I HeapMemoryUsage -J
used -vvvv
2. Have a 4GB or greater heap for the running process
3.

What is the expected output? What do you see instead?
OK - HeapMemoryUsage.used is
3300064800,committed=4286251008;init=2147483648;max=4286251008;used=3300064800
instead
CRITICAL - HeapMemoryUsage.used is
-659505464,committed=4286251008;init=2147483648;max=4286251008;used=3635461832

What version of the product are you using? On what operating system?
1.0

Please provide any additional information below.
Need this parseData method
    private long parseData( Object o )
    {
        if( o instanceof Number ) return ( ( Number ) o ).longValue();
        else return Long.parseLong( o.toString() );
    }

Original issue reported on code.google.com by christo....@gmail.com on 11 Jun 2009 at 6:44

[GoogleCodeExporter]

I have a similar problem too. The parse data returned by jmxquery.jar in some 
cases
is negative. In server side I have Jconsole that show me positive values, while 
in
jmxquery returns negative.

I´ve made a little script that test this minute a minute.

#!/bin/bash

while true 
do
java -cp /usr/local/semon/bin/plugins/jmxquery.jar jmxquery.JMXQuery -U
service:jmx:rmi://10.253.123.82:8084/jndi/rmi://10.253.123.82:8085/jmxrmi -O
WowzaMediaServerPro:mediaCache=MediaCache,mediaCacheStores=Stores,mediaCacheStor
e=d%3A%2Fmediacache%2Fcache1,name=MediaCacheStore
-A currentSize >> /tmp/foo.txt
sleep 60
done

And the results are:

JMX CRITICAL - currentSize is 0
JMX OK - currentSize is 135983016
JMX OK - currentSize is 423058272
JMX OK - currentSize is 730279160
JMX OK - currentSize is 815898096
JMX OK - currentSize is 1233919960
JMX OK - currentSize is 1309466080
JMX OK - currentSize is 1369902976
JMX OK - currentSize is 1772815616
JMX CRITICAL - currentSize is -2104129816
JMX CRITICAL - currentSize is -1842236600
JMX CRITICAL - currentSize is -1766690480
JMX CRITICAL - currentSize is -1716326400
JMX CRITICAL - currentSize is -1650853096
JMX CRITICAL - currentSize is -1444360368

Can you help us?
Thanks!

Original comment by luciano....@gmail.com on 18 Aug 2009 at 12:36

[GoogleCodeExporter]

It looks like the latest source code has the patch you need

Original comment by christo....@gmail.com on 18 Aug 2009 at 3:10

[GoogleCodeExporter]

I did some change in the code... looks like its working as we (I work with 
Luciano 
Castro) need.

boolean shown = false;
if (infoData == null || verbatim >= 2) {
  out.print(' ');
  long longunsignedcheckData = checkData;
  if (checkData < 0) {
    longunsignedcheckData = checkData & 0xfffffffl + 3221225472L;
  }
  if (attribute_key != null)
    out.print(attribute + '.' + attribute_key + " is " + longunsignedcheckData);
  else {
    out.print(attribute + " is " + longunsignedcheckData);
    shown = true;
  }
}

Original comment by maglov...@gmail.com on 20 Aug 2009 at 2:51

[GoogleCodeExporter]

It really bothered me that you had to do that ... that fixes checkData after the
value has ALREADY wrapped!!!
So I looked more closely at the latest source code and it DOES have the problem 
I
thought was fixed. The parseData function SHOULD look like this ...
        private long parseData(Object o) {
                if(o instanceof Number)
                        return ((Number)o).longValue();
                else 
                        return Long.parseLong(o.toString());
        }

I really have no strong affiliation with this project but since I stirred the 
issue
and invested this much in it I might as well keep going right ... ?! :-)

Original comment by christo....@gmail.com on 20 Aug 2009 at 4:04

Attachments:

• jmxquery.jar

[GoogleCodeExporter]

Christo! Thanks a lot! It´s Working now!! :-)

Original comment by luciano....@gmail.com on 24 Aug 2009 at 8:03

[GoogleCodeExporter]

Original comment by ryangrav...@gmail.com on 8 Dec 2009 at 10:16

• Changed state: Fixed

[GoogleCodeExporter]

I am still getting occasional negative numbers using the current stable release 
of this plugin.

Original comment by wlp1...@gmail.com on 29 Apr 2010 at 5:05

[GoogleCodeExporter]

Hi,

seems this issue should be re-opened as we are systematically getting negative 
HeapMemory.used values.
It seems that the version from 2009 is effectively fixed but that the bug 
reappeared.

Outputs from the 2009 version (the fixed one) :
java  -cp ./fixedversionfrom2009.jar jmxquery.JMXQuery -U 
service:jmx:rmi://localhost:8084/jndi/rmi://localhost:8085/jmxrmi -O 
java.lang:type=Memory -A HeapMemoryUsage -K used -I HeapMemoryUsage -J used 
-vvvv -username monitorRole -password admin -w 2505424895 -c 10582912000
JMX WARNING - HeapMemoryUsage.used is 
2516959232,committed=2545942528;init=263297600;max=12582912000;used=2516959232

Output from the 1.0 stable version (not fixed) :
java  -cp ./jmxquery-1.0.jar jmxquery.JMXQuery -U 
service:jmx:rmi://localhost:8084/jndi/rmi://localhost:8085/jmxrmi -O 
java.lang:type=Memory -A HeapMemoryUsage -K used -I HeapMemoryUsage -J used 
-vvvv -username monitorRole -password admin -w 2505424895 -c 10582912000
JMX OK - HeapMemoryUsage.used is 
-1960771584,committed=2554331136;init=263297600;max=12582912000;used=2334195712

Thanks, keep up the good work.
Raphaël

Original comment by raph...@enrici.com on 9 Dec 2011 at 5:02