An ehancement request from one of our Licensees (Sybase Inc) :
--------------------------------------------------------------

Consider the following:
A native application creates and instance of the JVM using JNI.  It passes
the appropriate parameters to have the VM start up the JPDA server.

However, if the JPDA server was not started with a port number, the server
chooses an appropriate port to listen on.  This port is then sent to
System.out or System.err ( not sure which one ).  In order for the native
application to read this information is must resort to redirection the
output to a file and then grepping the file for the information. There is
no API that could be used to retrieve this information from the java side.
I would like to have a class ( for example javax.jpda.ServerInfo ) that has
a method getPort() as well as other information.


raghunath.verabelli - 11/14/01 :

I agree with Sybase. We have encountered the same issue when implementing JPDA feature for Java Web Start (JWS), the only difference being the way in which the VM is being launched in debugging mode; Sybase does it through JNI, while Java Web Start calls an exec() system function. Please see below writeup from one of our engineers who worked on this issue.

JPDA compliant JREs from Sun include some -- albeit rather limited -- port selection logic.  This port selection logic can  be enabled by simply leaving out the "address=<port>" suboption in aforemetioned "-Xrunjdwp:..." command line option, i.e., the latter becomes:

       -Xrunjdwp:transport=dt_socket,server=y,suspend=y

This will cause the JRE to open a socket using an ephemeral port, and  to use this socket for communication with the debugger process.  The JRE process will also print this port to stdout of the process before the latter puts itself in suspend mode to wait for instructions from the debugger.

Obviously, this scheme will work well for users who *manually* invoke a
JRE ("java ..." command), through a console; the notification printed
to the console provides the user with the port number required to start
a debugger and to connect it to the JRE process.  Unfortunately, however,
this scheme doesn't work too well when the JRE is invoked *automatically*,
such as we know is the case in Java Web Start.  In Java Web Start, the
port selected by the JRE would somehow need to be communicated to the
"invoker" process, perhaps by redirecting stdout to a predefined socket
that the "invoker" listens on.  As a result, the selected port number is
printed to the socket instead, thus enabling the "invoker" to read it and
include it in the JPDA Notification window presented to the Java Web
Start user.  Other forms of interprocess communication could also be
used to communicate the selected port to the "invoker" process.


Name: tb29552			Date: 07/29/2004


A DESCRIPTION OF THE REQUEST :
When a VM launches with debugger without specifying the port number one is implicitly chosen by the operating system and printed to standard out.

Is there an internal System variable that JVM can locally inspect to determine if a debugger could be attached, and if so what the connection string (port) would be?

How could the Test JVM below know that it was running a debugger on port 4626 outside of redirecting standard out and parsing?

~$ java -Xdebug -agentlib:jdwp=transport=dt_socket,server=y Test
Listening for transport dt_socket at address: 4626


JUSTIFICATION :
By not explicitly specifying the port I don't have to worry about port clashes in my startup scripts, but it becomes difficult to determine what the port chosen was - or even if a debugger is running (outside of inspecting Thread names).

Often applications will have either a command line interface, or an application port already configured. It would be nice for the application to be able to inform programatically that a debugger is attachable and what the connector information is.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Interrogating the virtual machine API's for information (or environment variable) about the local JVM, which the application could do and remotely inform another management JVM for example.

ACTUAL -
Once the implicit port is chosen, it is printed to standard out and inaccessible to the JVM.

CUSTOMER SUBMITTED WORKAROUND :
Explicitly specifying the port number on startup, but then you have management issues with many JVM's and run into clashes with port numbers.
(Review ID: 290332)
======================================================================