When a profiling session cannot be established, the first thing to do is to have a look at the terminal output of the profiled application or application server. For application servers, the stderr stream is often written to a log file. This may be a separate log file and not the main log file of the application server. For example, the Websphere application server writes a native_stderr.log file where only the stderr output is included. Depending on the content of the stderr output, the search for the problem takes different directions:

Connection problems

If stderr contains "Waiting for connection ...", the configuration of the profiled application is ok. The problem might then be related to the following questions:

• Did you forget to start the "Attach to remote JVM" session in the JProfiler GUI on your local machine? Unless the profiling agent is configured to start up immediately with the "nowait" option, it will wait until the JProfiler GUI connects before letting the VM continue to start up.
• Is the host name or the IP address configured correctly in the session settings?
• Did you configure a wrong communication port? The communication port has nothing to do with HTTP or other standard port numbers and must not be the same as any port that is already in use. For the profiled application, the communication port is defined as an option for the profiling VM parameter. With the VM parameter -agentpath:<path to jprofilerti library>=port=25000, a port of 25000 would be used.
• Do you try to connect to an agent with a direct connection that only listens on the loopback interface? By default, the agent only listens on the loopback interface. You can configure JProfiler to set up an SSH tunnel to the remote machine. If you don't require encryption, you can also use the address=[IP address] option for the -agentpath parameter.
• Is there a firewall between the local machine and the remote machine? There may be firewalls for incoming as well as for outgoing connections or even firewalls on gateway machines in the middle.

Port binding problems

If stderr contains an error message about not being able to bind a socket, the port is already in use. In that case, check the following questions:

• Did you start the profiled application multiple times? Each profiled application needs a separate communication port.
• Are there any zombie java processes of previous profiling runs that are blocking the port?
• Is there a different application that is using the communication port?

If there are no lines in stderr that are prefixed with JProfiler> and your application or application server starts up normally, the -agentpath:[path to jprofilerti library] VM parameter has not been included in the Java call. You should find out which java call in your startup script is actually executed and add the VM parameters there.

Attach problems

When attaching to a running JVM, you sometimes may not see the JVM of interest in the list of all JVMs. To find the cause of this problem, it is important to understand how the attach mechanism works. When a JVM is started, it writes a PID file into the the hsperfdata_$USER directory in the temporary directory by which is it discovered. Only the same user or an admin user can then attach to the JVM. JProfiler can help you to connect to a JVM as an admin user.

On Windows, use the Show Services button to show all JVM service processes. JProfiler installs a helper service that will run with the system account that can connect to services running with system accounts as well as with a configured user account. The name of that service is "JProfiler helper" and is installed when you click on that button. You have to confirm the UAC prompt to allow the installation of the service. When JProfiler exits, the service is uninstalled again.

On Linux, you can use the user switcher in the attach dialog to attach with the root account. This user switcher is shown when profiling a local JVM as well as when attaching to a remote Linux or macOS machine. For the remote attach case, you can also switch to a different non-root user. If you have the root password, always switch to root rather than to the actual user that runs the service.

If a JVM is not visible on Linux even though you think it should be, the problem is usually connected with the temporary directory. One possibility is that the access rights for the /tmp/hsperfdata_$USER directory are wrong. In that case, delete the directory and restart the JVM. The process to be attached to must have write access to /tmp, otherwise attaching is not support.

If you use systemd, the process you are interested in may have PrivateTmp=yes set in its systemd service file. Then the pid file is written into a different location. JProfiler will handle this if you change to the root user with the user switcher in the attach dialog or if you use the CLI tools as root.