I am using Jetty 8 and trying to connect from Eclipse. I am using Java 1.6.
While starting jetty in debug mode, I am giving the below command which throws an "Address already in Use" error.
java -Xdebug -agentlib:jdwp=transport=dt_socket,address=8080,server=y,suspend=n -jar start.jar.
To do Remote debugging, I need open the debug mode on the same port in which Jetty server which is going to run.
The reason I suspect is, I am opening a debug port on 8080(done successfully) and when Jetty tries to start the server in default port 8080, it throws the error "Address already in use".
Can you help me?
Yes, the JVM allocates the port you specify for debugging, and it is unavailable for Jetty later. Unless explicitly coded, ports cannot be shared between purposes.
You should use another unused port for either of your purposes. I would suggest using 8000 or 7999 for the debugger port.
Note that modern versions of Eclipse allows for the reverse configuration ("listen"), i.e. that Eclipse listens on the port given and the JVM connects back to it. This might be relevant if you are debugging across a restricted network.
Related
I've made a script called debug.sh and placed it under the bin directory (start it with ./debug.sh) to start Tomcat 8 in debugging mode:
set JPDA_ADDRESS=8000
set JPDA_TRANSPORT=dt_socket
set JAVA_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n
bash catalina.sh jpda start
But if it started, there is now message which says, that Tomcat is listening on port 8000. Also if I type
netstat -nat
there is no application listening on port 8000.
What exact configuration do I have to set, to remote debug my Tomcat 8 server which is running on a specific IP or do I have just a little problem in my script?
This answer has been updated following the comments, I did not understand the problem in the first place.
I guess you have followed that doc: this is about developing Tomcat itself.
I am not sure you are using the proper way to configure the port (I don't know your specific configuration details). In a standard environment, the ports are configured in the server.xml (note that several different ports are used by Tomcat for the different services).
To remotely monitor your server, you should use a JMX client. As far as I know, Eclipse doesn't include one (or at least not one documented) - you could code one as this is a Java specification (JSR262). You have one in a standard Java environement (JConsole). By default, JMX is not enabled on Tomcat. If you need to enable it, the fine way is to follow the doc.
Tomcat JMX monitoring and JConsole are both available in most versions of Tomcat and the Java runtime.
The following exchange seems to be about your problem.
I came to know of the remote debugging procedure under Idea recently. What I do is copy the configuration of remote debug under Run | Debug Configuration in Idea to the command line java execution parameters. The actual command line parameters are:
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000
If it is a script, I add these commands to it. By doing so, the command line displays the message:
Listening for transport dt_socket at address: 8000
So the debugging can happen using the local source code. However, I don't properly understand how remote debugging work. Anyone who knows how remote debugging actually works, please give me an explanation.
Thank you!
Remote debugging means that you can run your Java code anywhere, either on the local or remote machine. When it's running in the debug mode, you can connect to it from the IDE using TCP network connection and perform debugging. IDE needs to have the source code for the running classes so that you can place breakpoints inside this code and perform stepping, inspecting variables, etc.
If you are interested in technical details, refer to the JPDA documentation.
Consider a scenario where you want to fix something in your application but your application only can run over a server machine because of other dependencies.
That is where Remote Debugging come into picture. You Just connect the sever by providing the hostname and port and connect it with your respective environment.
How It works:
Application to be debugged will attach a socket to itself and then will start listening debug instructions.
Debugger will bind itself to that socket and then send instructions.
This is best way to test your code which are in different environment .
we need to have below points for sure before you are using remote debug .
we are using JBOSS in our servers.
configure - JBOSS_HOME/bin/run.conf
JAVA_OPTS="${JAVA_OPTS} -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"
now add the server IP and port number into the intellij remote debugging .
4.your should have the latest version of the project in local that is in synch with the server else debug will not be allowed.
you need to start the intellij server for the project .
Then start the remote debug .
place a debug point in local and when we start testing in the server , when it hits the debug point it will stop and wait untill you process it .
The other point is , it will hold all the request in the queue and will not allow anyone to go through the break point which may stop other users to test it .
I have a web application. It is currently deployed on a remote server in a Glassfish instance. Is it possible to remotely connect to the server and debug the application (like I would a normal java application) using Netbeans?
If someone has done this and could provide insight or could point me to a guide, that would be great.
I know this functionality exists with Visual Studio and ASP.Net. I was not sure if there is a java equivalent.
Most examples that I have seen online are for applications that are simply running on a remote machine or for debugging a Glassfish application running on the local machine.
Yes, it is possible.
Once you have GlassFish running in debug mode, go to the Debug menu in NetBeans and click on Attach Debugger..., which brings up the Attach dialog. You'll probably go with something like:
Debugger: Java Debugger (JPDA)
Connector: SocketAttach
Transport: dt_socket
Host: hostname_or_ip_address
Port: 9009
Timeout may be left blank. When you click OK on this dialog, you should be able to connect your NetBeans debugger to GlassFish.
Remember:
The firewall on your remote server (and any gateways in between) should allow connections to the debugger port (9009 in my example).
Make sure you're using matching port numbers. In the GlassFish admin console, usually at: http://localhost:4848
Expand Configurations.
Expand server-config (or whichever you are using).
Click JVM Settings.
Check Debug to Enabled.
Verify that Debug Options contains:
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=9009
Read the JPDA docs for other options you can use.
The server is in debugging mode. I've set 10 breakpoints and the browser just skips them all. Why? This happens with JSPs also in that project. Why?
Have you checked that the Debbuger is indeed connected with Glassfish? Also please note that it is not possible for the debugger to stop at breakpoints which have been set inside jsp. AFAIK, debugger works only pure java code
So you are connecting to external server with "debug remote java application".
What is your server's debug port? Port 8000 is default setting in eclipse debug configuration for remote java appilcation. You should change that value to one that GlassFish server is configured for debugging.
Also, take a look at How do I debug GlassFish 3 using Eclipse Helios?
Now resolved - see end of question.
I am attempting to debug a Java process with IntelliJ Community Edition's debugger. The socket is listening - but when I try to connect the debug process shows the following
'Connecting to the target VM, address: ':8003', transport: 'socket'
It never makes the connection to the VM and I cannot debug.
I have moved to a Windows 7 64 bit PC - on my old XP machine and could connect and debug this Java process (it's an app I build and maintain).
It does not fail with the standard "Connection refused: Connect" error that you would get if no process was there to connect to. Netstat also shows the port is listening when the app is running.
TCP 0.0.0.0:8003 :0 LISTENING
Debug args for the app
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8003
-Xdebug
If I attempt to run the debug session from IntelliJ on a remote machine, I can connect to the process running on my local machine, and debug.
If I run the Java app on a remote machine, and use IntelliJ on my local machine, I can debug.
It is only if I run and debug on the same machine that it fails - unfortunately this is what I need to do almost all the time.
The only similar issues I have found are from 2004, to do with file paths with spaces, and were NetBeans, not IntelliJ. I have rebuilt and rerun my app ensuring no spaces or underscores in the path, no joy.
My intelliJ debug settings are to debug my local machine on socket, attach mode port 8003 - sorry as a new user I can't attach an image.
Other things I have attempted:
Changing JRE versions
Debugging using shared memory rather than socket transport
I have not re-installed IntelliJ - I am using the same build as my fellow devs (10.5 IC 107-105) who don't have this problem.
Changing the port the debugging process listens on (from 8003 to various other, unused according to netstat)
I have tried using PC name, IP Address and 'localhost' to refer to the PC in the debug settings.
Stuck. Any help much appreciated.
Thanks
Steve
Resolved
Well, a day of failing to solve then I find the answer 20 mins after posting. An invalid JNI signature character, only picked up when debugging. Solved by adding this arg when debugging.
-Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6547438
Thanks for the assistance. Still don't know why it would work when debugging remotely but not locally before.
It sounds like a strange firewall issue.
It appears that you should be able to try telnet localhost 8003 and it should fail. This means nothing can connect to your app on that port.
EDIT: If shared memory does work either and you cannot connecft it via telnet, there is a problem with the way you are running the app.
You will get this type of error if the application is not running.
Can you try debugging a simple program you lauch from IntelliJ?