search

me0wster / javamelody

Automatically exported from code.google.com/p/javamelody
0 stars 0 forks source link

graph issues/64-bit? #190

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
graphs are missing descriptions, scaling is different than traditional setups 
(many other of my apps on 32-bit env are fine, and in fact this one without 
changes works fine on 32-bit env (tomcat6), but moved to 64-bit (virtualized) 
env now seeing problems).

See attached image.  Been seeing issue for couple of weeks trying to see if 
'letting it settle' would make a difference.

What version of the product are you using? On what application server, JDK,
operating system?

Java:   Java(TM) SE Runtime Environment, 1.6.0_14-b08
JVM:    Java HotSpot(TM) 64-Bit Server VM, 14.0-b16, mixed mode
OS: Centos 5.4 x86_64, kernel: 2.6.18-164.15.1.el5xen 
appserver: tomcat6

Please provide any additional information below.
javamelody 1.26
jrobin 1.5.11
--RRD files have been deleted to start from scratch to verify, still issue.

web.xml fragments:
=====================================
<filter>
        <filter-name>monitoring</filter-name>
        <filter-class>net.bull.javamelody.MonitoringFilter</filter-class>

        <init-param>
            <param-name>displayed-counters</param-name>
            <param-value>http,sql,error,log,ejb</param-value>
        </init-param>

        <init-param>
            <param-name>storage-directory</param-name>
            <param-value>/var/log/tomcat6/javamelody-myapp</param-value>
        </init-param>
        <init-param>
            <param-name>resolution-seconds</param-name>
            <param-value>600</param-value>
        </init-param>

    </filter>
    <filter-mapping>
        <filter-name>monitoring</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

    <listener>
        <listener-class>net.bull.javamelody.SessionListener</listener-class>
    </listener>

=========================

Original issue reported on code.google.com by binarymo...@gmail.com on 24 Feb 2012 at 4:01

Attachments:

GoogleCodeExporter commented 9 years ago 
One note -- we are using non-standard tomcat ports (multiple tomcat instances 
running on a single box with different ports).  I'm doing some additional 
testing around this....

Original comment by binarymo...@gmail.com on 24 Feb 2012 at 4:21

GoogleCodeExporter commented 9 years ago 
Hi,
I see that there are also missing labels in the graphics, so perhaps it is a 
problem with fonts in this new environment (64bits, CentOS, OpenJDK ?).
In order to confirm or not that possibilitiy, I suggest to look in the server 
logs for stack-trace(s) near the start of the server and then to read 
javamelody issue 144.

One other thing that strikes is that you said "jrobin 1.5.11" (and not the 
recommended jrobin 1.5.9). The problem is that that jrobin 1.5.11 is not tested 
by javamelody users in general and that they have changed some stange things in 
JRobin lately such as the default backend factory. See the end of 
http://sourceforge.net/mailarchive/message.php?msg_id=28038427 , which did not 
have a response yet.
Have you tested the same with jrobin 1.5.9?

Side note: we could be more active in the jrobin project by submitting JIRA 
issues and git patches:
http://issues.opennms.org/browse/JRB

Original comment by evernat@free.fr on 26 Feb 2012 at 12:02

GoogleCodeExporter commented 9 years ago 
Fonts are the same on both environments (one that works and the one that does 
not).  On linux, you can check /usr/share/fonts then various subdirs. I also do 
not get the stacktraces similar to issue 144 (no stack traces at all actually, 
and everything is fine except the graphs).

The java/jvm above came from javamelody directly versus command line, so I know 
tomcat itself is running hotspot/sun (unless openjdk says the same thing in 
javamelody details?).

Jrobin 1.5.9 was what I was always using, and this problem was occurring with 
1.5.9.   Reviewing http://issues.opennms.org/browse/JRB-3 I thought 1.5.11 may 
or may not help, but it did not.

If there is anything else I should do to help provide more information or test 
other areas, let me know.  I have not completed the non-standard tomcat ports 
test yet, but that is still on my list of variables that may be causing the 
issue.

Original comment by binarymo...@gmail.com on 27 Feb 2012 at 7:30

GoogleCodeExporter commented 9 years ago 
(p.s. using the javamelody details to get the java/jvm information is a great 
starter for anyone to provide information back and should be part of the guide. 
 With linux, you have several potentials where the commandline 'java -version' 
is not the same as what tomcat itself is running with server/sysadmins changing 
things like JAVA_HOME for tomcat user envs, 'alternatives' setting different 
default jvms, versus older jpackage (jpp) based tomcat installs using java in 
their own way).

Original comment by binarymo...@gmail.com on 27 Feb 2012 at 7:34

GoogleCodeExporter commented 9 years ago 
port 8080 versus non-standard port does not seem to be the issue.

Tested adding "-Duser.language=us_en -Duser.region=US" to the startup of tomcat 
(ref: http://issues.opennms.org/browse/JRB-7), stop tomcat, cleared RRD files, 
started backup, still same issue (graphs without descriptions).

Original comment by binarymo...@gmail.com on 8 Mar 2012 at 9:45

GoogleCodeExporter commented 9 years ago 
Further testing and more information, there may be little that can be done but 
detailing:

*setting java.awt.headless=true (with the above other changes, both with jrobin 
1.5.9 and 1.5.11) do not change the outcome, the graph headers are still as 
pictured.

*openjdk versus sunjdk do not seem to make a difference (the jdk version, not 
just jre)

*the issue is only occurring on two specific 64-bit centos systems, however 
additional testing on the same uname -a/release/xen virt environments 
javamelody graphs work as expected. Checking locale on the same environments, 
as well as fonts, showed no difference between ones that have correct 
javamelody graph headers and those that do not.

--it appears that the specific environment causing the graph issues above is 
related to some custom scripting approach that allowed multiple tomcat ports on 
the same box with Webmin control over those tomcats -- I do not have a 
reference, as it was 'custom' internal.  That is the only identified difference 
between the problem javamelody graphs, and other (similar) systems that work 
fine.

all other parts of javamelody seem to operate without issue other than the 
graph header descriptions.  

Unless there is some recommendations of areas to check in tomcat or the system, 
this may be a 'wont fix' ticket as even I haven't been able to reproduce the 
problem on different systems.

Original comment by binarymo...@gmail.com on 13 Mar 2012 at 1:02

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Reading this issue again, I think that trying java.awt.headless=true was a good 
idea (even if it did not work this time).

Looking again at the screenshot, it appears that all letters [a-z] from labels 
are not displayed, but some other characters such as '%', '(', ')' and '1' are 
displayed. For example the label "Http mean times (ms) - 1 day" is displayed in 
the middle, but without the letters.

I would suggest to check if there is a DISPLAY environment variable in the 
shell launching java and to remove it if there is one (add 
-Djava.awt.headless=true if it is not there yet, then restart the server).

Otherwise, check if there is a valid DISPLAY environment variable available for 
the OS user and add it if there is none (start something like XFVB to have a 
dummy window server if needed), and also remove "java.awt.headless=true" then 
restart the server. But yes, this is just throwing random ideas without being 
sure, and a linux "expert" may have a better answer than me.

Original comment by evernat@free.fr on 9 Apr 2012 at 4:42

GoogleCodeExporter commented 9 years ago 
And when looking for stack traces in the server log, you have looked in the 
standard output and in the standard error (probably redirected to a file from 
your script), not only in your log4j or logback file?

Original comment by emeric.v...@gmail.com on 9 Apr 2012 at 5:29

GoogleCodeExporter commented 9 years ago 
Hi,
Did you have some success with system fonts/headless/DISPLAY perhaps?
Any other news on this issue? Or can we close it as "can not reproduce / won't 
fix" as suggested?

Original comment by evernat@free.fr on 16 Dec 2012 at 12:24

GoogleCodeExporter commented 9 years ago 
so closing as can not reproduce / won't fix this font problem

Original comment by evernat@free.fr on 20 Jan 2013 at 2:08