JDK-7009828 : Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6u23,6u24,7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,windows
  • CPU: x86
  • Submitted: 2010-12-30
  • Updated: 2017-10-22
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u25Fixed 7Fixed OpenJDK6,hs20Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
I encountered this problem while trying to monitor Tomcat 6.0.29 with visualvm 1.3.1 running  Java 1.6.0_23 -b05.

  To reproduce:

1. Start Tomcat with its default settings
2. Start visualvm with its default settings (on the same system)
3. Tomcat will not be visible in visualvm


1. Launch visualvm with -J-Djava.io.tmpdir=$CATALINA_HOME/temp

This will allow you to monitor Tomcat on the same machine, but then no other Java processes can be monitored (such as Java DB).

2. Point Tomcat's temporary directory to /tmp (%TMP% or %TEMP% on Windows).

This will allow you to monitor all Java processes that use the default temporary directory, but may create problems if more than once instance of Tomcat running the same application is started (single host clustering, for example).

In general, any Java application that sets java.io.tmpdir can no longer be monitored by visualvm or jconsole (and I suspect other tools).

A separate property may be useful to define where performance information is written.

Monitoring Java applications locally with available tools is no longer practical if the application defines its own java.io.tmpdir. Mapping this to the system-wide location can create problems when more than one instance of that application is running on a single host.

A new property could be used (java.io.hperfdir) to separate performance information from application information. java.io.hperfdir could default to /tmp (%TMP% or %TEMP% on Windows). This would allow Java applications to write temporary files in a developer-specified location without impacting monitoring.
See bug description

Running monitoring applications with -J-Djava.io.tmpdir=(application java.io.tmpdir) works if you only wish to monitor that application. Setting the application's java.io.tmpdir to the system default works as long as the applications don't create conflicting file names. Conflicting file names are likely when more than one copy of a servlet container such as Tomcat is being run.

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/34d64ad817f4

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/34d64ad817f4

EVALUATION Summary: Change get_temp_directory() back to /tmp and %TEMP% like it always was and where the tools expect it to be.