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 startup.
• 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 to 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.