United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4527279 Need a better way to find out the port number on which JPDA is listening.
JDK-4527279 : Need a better way to find out the port number on which JPDA is listening.

Details
Type:
Enhancement
Submit Date:
2001-11-14
Status:
Resolved
Updated Date:
2005-06-02
Project Name:
JDK
Resolved Date:
2005-06-02
Component:
core-svc
OS:
solaris_9,generic
Sub-Component:
debugger
CPU:
sparc,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.4.0,5.0
Fixed Versions:

Related Reports
Duplicate:

Sub Tasks

Description
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)
======================================================================

                                    

Comments
SUGGESTED FIX

For some ideas on how this RFE might be implemented, please see
part B-2.1 in the "Known Bugs" section of document:

	http://web-east.east/~sbohne/carlos/RFE4462959/
                                     
2004-07-30
WORK AROUND

 > 	From: Jim Holmlund <###@###.###>
 > 	MIME-Version: 1.0
 > 	Content-Transfer-Encoding: 7bit
 > 	To: ###@###.###
 > 	CC: ###@###.###
 > 	Subject: Re bug 4527279: Need a better way to find out the port number 
 > on which JPDA is listening.
 > 	
 > 	
 > 	I wonder if the 'launch' feature of the JPDA connector
 > 	would help you.  See:
 > 	
 > 	     http://webwork.eng/j2se/1.4/docs/guide/jpda/conninv.html
 > 	
 > 	For example:
 > 	
 > 	/home/jjh/try.sh contains:
 > 	-----------------------------
 > 	#!/bin/sh
 > 	
 > 	echo "In try.sh: echo args = $*"
 > 	--------------------------------
 > 	
 > 	Hello is a typical Hello.java program except it loops printing out its 
 > 	msg.
 > 	
 > 	Here we run it with the launch option:
 > 	
 > 	java -Xdebug 
 > -Xrunjdwp:transport=dt_socket,server=y,suspend=n,launch='/home/jjh/try.sh' Hello
 > 	In try.sh: echo args = dt_socket 48723
 > 	Hi from Java!
 > 	Hi from Java!
 > 	Hi from Java!
 > 	Hi from Java!
 > 	
 > 	Note that the program named in the launch option is executed
 > 	after the debugger code in the VM has been initialized and it is
 > 	passed the transport and address.  
 > 	
 > 	We can run it without the suspend=n option too to cause it
 > 	to be suspended (after launching the 'launch' program.)
 > 	
 > 	In this case, the program is a shell script but I think
 > 	it could be an a.out also.  So, you could write a C program
 > 	to get the address and do whatever you wanted with it,
 > 	ie, you could implment your own shared memory scheme to transfer
 > 	it to your other program, you could write it to a socket
 > 	your other program knows about, write it to a common file, ...
 > 	register it in a registry that your debugger would interrogate, ...
 > 	
 > 	Do you think this would work for Sybase?
 > 	

Raghunath Verabelli - Sun Microsystems writes:
 > This is the feedback from Sybase :
 > 
 > I have looked into this a little with a small sample under NT.  It looks
 > like this will work. Thank you.
 > 
 > [d:\] type jpda_cap.bat
 > =====================================
 > @echo off
 > echo Inside of jpda_cap: Args = %*
 > =====================================
 > 
 > [d:\]java -Xdebug
 > -Xrunjdwp:transport=dt_socket,server=y,suspend=n,launch=jpda_cap.bat
 > Hello
 > ========================================================================
 > ====================
 > Hello
 > HelloInside of jpda_cap: Args = dt_socket 1108
 > 
 > Hello
 > Hello
 > ========================================================================
 > ====================
 > 
 > [d:\]java -Xdebug
 > -Xrunjdwp:transport=dt_socket,server=y,suspend=n,launch=jpda_cap.bat
 > Hello
 > ========================================================================
 > ====================
 > Inside of jpda_cap: Args = dt_socket 1109
 > Hello
 > Hello
 > Hello
 > Hello
 > ========================================================================
 > ====================
 > 
 > [d:\]java -Xdebug
 > -Xrunjdwp:transport=dt_socket,server=y,suspend=n,launch=jpda_cap.bat,add
 > ress=3333 Hello
 > ========================================================================
 > ====================
 > Hello
 > HelloInside of jpda_cap: Args = dt_socket 3333
 > 
 > Hello
 > Hello
 > 
 > 
 > 
 > --
 > Raghunath Verabelli              
 > Java (tm) Partner Engineering
 > Sun Microsystems Inc.
 > Phone : (781)442-4517.
 > 
 > 
                                     
2004-07-30
EVALUATION


In b39 we have added a new AttachingConnector with name com.sun.jdi.ProcessAttach. This can be used by a debugger to attach to a debuggee by process-id (pid) without know the transport or transport address.
###@###.### 2005-05-19 10:37:50 GMT
                                     
2005-05-19



Hardware and Software, Engineered to Work Together