Trouble Shooting Connection Problems
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:
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.
- 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.
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
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
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