Identify Java jdwp Debugger Assigned (Ephemeral) Port

Question

I am using the following JVM parameters to start-up a JVM with the hostpot debugger.

-Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=0

Note that I am assigning port zero, so that the JVM asks the OS for an ephemeral port. This is critical for my use-case, to make sure the JVM will not fail to start-up due to contention for some pre-defined port.

As a result my JVM starts-up, and the following log entry is outputted to stdout:

Listening for transport dt_socket at address: XXXX

I would like to find some way to identify the debug port from inside or outside of the JVM, so it would be possible for me to record it in a state management serverice.

What options are available for this use-case? I have considered the following, with little joy:

• JMX Connector - Connect using JConsole to the process, find some MBean which details which port was use. However, I cannot find any such MBean
• RMI Registry - Is it possible to have the debug agent register itself against an RMI Registry? I've not found any evidence this could work.
• Java Agent - Specify a JVM agent that could intercept some aspect of the debugger and obtain the port details, again no evidence to support the feasibility of this idea.

Compatriot

Run a program to assign the port and release it instead of passing 0 here. It's how, for example, the build-helper-maven-plugin works. – Broder

@Broder - That assumes that no other process opens the same port number in the time between the wrapper closing it, and the application opening it. This makes me feel a little uneasy in a production application. – Compatriot

Answer 1

From within VM:

    Properties props = sun.misc.VMSupport.getAgentProperties();
    System.out.println(props.getProperty("sun.jdwp.listenerAddress"));

From outside application:

    VirtualMachine vm = com.sun.tools.attach.VirtualMachine.attach(PID);
    try {
        Properties props = vm.getAgentProperties();
        System.out.println(props.getProperty("sun.jdwp.listenerAddress"));
    } finally {
        vm.detach();
    }

Both are not a part of a standard. Applicable only to OpenJDK / Oracle JDK.

Fanfare

This is successful. Note that this option is only exported if the server=y argument is specified as part of ` -Xrunjdwp:server=y,transport=dt_socket,address=1234,suspend=n` – Compatriot

Answer 2

Maybe something you could start with.

netstat -tlnp

This gives you a list of all processes listening on a local TCP port. For example:

tcp    0    0 0.0.0.0:35688     0.0.0.0:*     LISTEN   26733/java

35688 - the ephemeral port
java  - the program name which is listening
26733 - the PID of the process 

If you need a finer granularity of the java processes you could use ps to gather informations about the process.

ps x -p 26733

could return something like

26733 pts/1 0:00 java -Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=0 Scratch

Chestonchest

The problem I forsee here is that the application opens more than one ephemeral port, as it has other general network use-cases. Therefore, it would be difficult to distinguish between the jdwp port and the other ones. – Compatriot

You mean you start several processes which would have the command line? – Chestonchest

No, to clarify. If the application opens more than one port, netstat will list all the ports that belong to the process. Therefore it would not be possible to identify which of the ports the debugger is listening on. – Compatriot

Ok. This was not clear. Maybe trial'n'error could work (depends what is listening on the other ports). The ephemeral port is choosen by the operating system and the native library jdwp does not report it to the JVM. Parsing the output string of the JVM which runs the listener could also be an option. – Chestonchest

@Compatriot One additional comment: When you start your application for debugging then the only listening port will be debugger. So other ports will be opened later by you application wouldn't a problem at this stage. Isn't? – Chestonchest