A DESCRIPTION OF THE REQUEST :
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

Workarounds:

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.

JUSTIFICATION :
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.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
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.
ACTUAL -
See bug description

CUSTOMER SUBMITTED WORKAROUND :
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.