| Summary: | jps.exe and jvisualvm.exe cannot detect tomcat using jdk1.6.0_23 | ||
|---|---|---|---|
| Product: | Tomcat 7 | Reporter: | quaff <zhouyanming> |
| Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
|
Description
quaff
2010-12-24 00:29:33 UTC
Bugzilla is not a support forum. Please ask this question on the Tomcat Users mailing list. This is a bug. I can confirm that the same happens with Tomcat 6.0.26. This problem is specific to Tomcat and jdk 1.6.0_23. All other applications I have tried are reported to jps and jvisualvm without problems. It also works for Tomcat and jdk 1.6.0_22. Please note that a new JVM version 19.0 was introduced in 1.6.0_23. I have tracked down the problem to the fact that both jps and jvisualvm detect running JVMs by looking into /tmp/hsperfdata_$USER directory, which is created automatically by all SUN JVMs since JDK 1.4.0_02. For some unknown reason the JVM running Tomcat does not create the files in the /tmp/hsperfdata_$USER directory. Even using -XX:+UsePerfData doesn not help. This bug prevents monitoring production servers running Tomcat with jvisualvm. A very short investigation shows the issue. 1) Tomcat specifies -Djava.io.tmpdir=$CATALINA_BASE/temp in its JVM options. 2) Java 6 Update 23 places the hsperfdata_$USER directory in this directory rather than in the normal location where jps, visualvm, etc, expect it. It looks like Oracle needs to either undo this change or provide a means of decoupling these directories, e.g. a temp dir setting that does *not* change the hsperfdata location. I believe this is a bug in Java 6 Update 23. If hsperfdata is to be placed in other locations then jps, visualvm, etc, must know how to find it. This seems unreasonable, so I'd conclude that the hsperfdata location should not be impacted by the java.io.tmpdir setting. I briefly tested a temporary work-around. Launch visualvm as follows: visualvm -J-Djava.io.tmpdir=(Tomcat temp directory) There are some caveats. The user running visualvm has to have the correct permissions in order to read the hsperfdata_xxxx data. That instance of visualvm will not be able to monitor other Java processes on the system. This looks like fallout from the following: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6938627 We can close this issue then, as this is a Java problem and not Tomcat specific? Thank you for your investigation. Looks like something that we cannot fix, but we may mention it in RELEASE-NOTES, or on the FAQ page on the Wiki site (editable by everyone). It is a regression in JDK and concerns not only Tomcat, but any java application that runs with its own value of java.io.tmpdir. (In reply to comment #3) > A very short investigation shows the issue. > > 1) Tomcat specifies -Djava.io.tmpdir=$CATALINA_BASE/temp in its JVM options. Note, that if you are using catalina.(sh|bat) to start Tomcat, then the path to the temporary directory can be customized by setting the "CATALINA_TMPDIR" environment variable. One can set it either before running the scripts, or in a bin/setenv.(bat|sh) file. > 2) Java 6 Update 23 places the hsperfdata_$USER directory in this directory > rather than in the normal location where jps, visualvm, etc, expect it. > Yep - this is a JVM issue, not a Tomcat bug. I've added a known issues section to the FAQ. (In reply to comment #8) > I've added a known issues section to the FAQ. For reference: The known issues FAQ page is [1]. The Sun/Oracle bug page for this issue is [2]. [1] http://wiki.apache.org/tomcat/FAQ/KnownIssues#OracleJREIssues [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7009828 |