I am trying to run remote jboss in debug mode to debug my application and i have set
set JAVA_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y %JAVA_OPTS%
in run.bat file, and am trying to start the jboss server using ant jboss.start but it is taking some time and then timing out, am not sure why this is happening, is there a way out?
Also as jboss is timing out, I would like to increase bootup time for the server, how can i do it from the command line?
Side note, server.log file does not show any messages which jboss is trying to bootup in debug mode (not sure if this would help but thought so sharing this info.)
Any clue or suggestions?
You should set:
suspend=n
in debugger startup settings.
suspend - True if the target VM is to be suspended immediately before the main class is loaded; false otherwise.
Your JBoss waits infinitely for debugger connection, this is useful when you want to troubleshoot startup issues, otherwise do not suspend your VM and let the debugger be connected any time you want.
I was frustated to get jboss started in debug mode through command line
Finally following seemed to work
1.Below should be the last line in /bin/run.conf.bat
rem # Sample JPDA settings for remote socket debugging
set JAVA_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n %JAVA_OPTS%
If there is anything below this, delete it.
2.Also when you are running jboss from command prompt please check whether -Xdebug is at the start of JAVA_OPTS.
Then it should display following message
Listening for transport dt_socket at address: 8787
3.In eclipse use 127.0.0.1 instaed of localhost.
I don't know the reason behind it...but when I changed localhost to 127.0.0.1 it worked
(Make sure you replace localhost with 127.0.0.1 at 2 locations 1.Eclipse remote debug and 2.URL while running your application in browser)
Also check project name.
Sometimes we need to change the port number.
I never had such issues with tomcat.
Related
Ok, I think I tried everything before I am posting this question. Please tell me, what I am (Still) missing. I keep getting "unable to connect" exception (unable to connect hostname:6012), I changed from default port 1099 and it still didn't help.
version of IntelliJ 14.0.2
Tomcat 7.0.52
Tomcat is running as a service so, I configured on the UI interface of tomcat.exe (java tab) the following JAVA_OPTs
-Xdebug
-Xrunjdwp:transport=dt_socket,address=57497,server=y,suspend=n
-javaagent:C:\Users\username\.IntelliJIdea14\system\groovyHotSwap\gragent.jar
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=6012
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Dcatalina.home=C:\Tomcat 7.0
-Dcatalina.base=C:\Tomcat 7.0
-XX:MaxPermSize=512m
I made sure the port 57497 is open (open the firewall and telnet).
And on IntelliJ, I made a remote server connection. Please find attached
pictures. Both intellij and tomcat are running on the same system. I have a static dns setup. sometimes i get connection timedout exception.
server tab
connection tab
Here's my config.
Tomcat JAVA_OPTs to enable remote debugging:
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5007
In IntelliJ, I don't use the Configuration-Type 'Tomcat'. In my case 'Remote' works pretty well (I would post an image but I ain't got 10 reputation...). You only need to configure your host and port on the config sheet.
I use IntelliJ 14.0.3 and I had the same issue, though with Jetty. Switching to using the remote instead of jetty -> remote worked. I'm guessing they're both supposed to work differently. I just haven't figured out why there are two different options to remote debug.
I run Jetty from the command line with:
export GRADLE_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,address=9999,server=y,suspend=n"
gradle jettyRun
and see:
Listening for transport dt_socket at address: 9999
... then in IntelliJ Idea (Ultimate 12.1.3) I create a new remote debug configuration with all defaults, changing only the port to 9999.
When I start (debug) using the remote configuration, I see:
Connected to the target VM, address: 'localhost:9999', transport: 'socket'
... which makes me think everything is working as expected.
Then I make requests that should result in hitting breakpoints. But the breakpoints are never triggered.
What am I doing wrong?
Thanks.
You could have the "org.gradle.jvmargs" variable set in your gradle.properties file. This causes the JVM to be forked which means you are no longer debugging the right process.
In this case, you could either not set the "org.gradle.jvmargs" or pass it the debug parameters eg.
org.gradle.jvmargs=-XX:MaxPermSize=128m -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=1233
Setting the debug parameters in org.gradle.jvmargs would configure the forked process for debugging.
In IntelliJ (at least on 12.1.5) you can just go to JetGradle, right click on jettyRun and then click on Debug.
In intelliJ 12.0 on ubuntu 12.04 with glassfish 3.1.2.2, I'm trying to launch my web application in debug mode but I've got this error message:
Error starting domain domain1.
The server exited prematurely with exit code 134.
Before it died, it produced the following output:
FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
ERROR: transport error 202: bind failed: Address already in use
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [../../../src/share/back/debugInit.c:741]
I try to change the port 9009 in the domain.xml by another one but it was unsuccessful.
Could you help me to fix this problem?
Thank you
I had this same problem too a few weeks ago. I dont remember 100% what I changed but I know it has to do with the file $GLASSFISH_HOME/glassfish/domains/domain1/config/domain.xml. If I recall I think I changed the following line:
<java-config debug-options="-Xdebug -Xrunjdwp:transport=dt_socket,server=n,suspend=y,address=9009" system-classpath="" classpath-suffix="">
In particular server and suspend flags. When I set them like this the error you described above went away.
I had the same problem, and was because the debug port 9009 had beeen occupied by the DbVisualizer application. DbVisualizer uses some random ports, and at this time, it chosed the 9009. In my case, I only had to close DbVisualizer and GlassFish started up in debug mode fine.
So, check out no processes have occupied your Glassfish debug port.
Another possible solution is to change this port, or use shared memory.
Regards
In recent versions of IntelliJ the application is aware of invalid settings for debug mode. If this is the case, when you open the Run/Debug configuration of your Java EE server, in the bottom you will see a warning message:
Just press the fix button and you will fix your 'domain.xml' configuration file.
This is also explained in this tutorial: https://www.jetbrains.com/help/idea/2016.1/developing-a-java-ee-application.html
For the future poor soul that has the same issue as me:
One of the tools that comes with Gigabyte mainboards (gCloud I believe) registers a Windows service on port 9009. This port then shows up in netstat -ano as being in use by PID 4 (Windows system something).
I am working on a project where the backend code is in Java.
I want to debug this code and am running tomcat in the debug mode correctly .
I have the Java code in Eclipse where I set up a new debug config for Remote Java Application and start the debugging.It shows no error but it is not breaking at the breakpoint.
So the Tomcat Webapps folder has only a copy of the Servlet classes and my Java code is in a folder at some other place.
Is this the reason that I am not being able to link them properly
You have to start tomcat with the JPDA options in order to debug remotely. Under *nix, issue "catalina jpda start" instead of "catalina start".
If you want to do a remote debug to figure out a problem in code, then your code locally must be the same. Also remember to connect to the correct port, 8000, I believe.
When I add the following Java options to enable debugging:
JAVA_OPTS="$JAVA_OPTS -noverify -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005"
I get the following error whenever I try to shutdown the tomcat:
ERROR: transport error 202: bind failed: Address already in use ["transport.c",L41]
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510) ["debugInit.c",L500]
JDWP exit error JVMTI_ERROR_INTERNAL(113): No transports initializedFATAL ERROR in native method: JDWP No transports initialized, jvmtiError=JVMTI_ERROR_INTERNAL(113)
Thank you for a nice short explanation, PHeath! Following your advice, I found the best way to solve the problem is simply to use CATALINA_OPTS instead of JAVA_OPTS.
Looking into catalina.sh, one can see CATALINA_OPTS is only used by the "start" and "start-security" commands, whereas JAVA_OPTS is also used by the "stop" command (at least with Tomcat 6.0.33 on openSUSE 12.1).
At least if you have Tomcat installed on Linux using a package manager then modifying the CATALINA_OPTS variable in /etc/tomcat6/tomcat6.conf (or whatever path in your distribution) is cleaner than changing the catalina.sh script directly, for the package manager assumes that the user changes only configuration files and breaking this assumption may cause problems when upgrading the Tomcat packages (e. g. lost settings because the catalina.sh file is overwritten).
I think one should prefer CATALINA_OPTS over JAVA_OPTS not only for JDWP but for many other options as well: e. g. if one uses the heap size option -Xmx... then it would be reasonable to put it into CATALINA_OPTS, as the "stop" command does not need much heap.
You are trying to debug tomcat on startup, so it binds to port 5005 when the jvm starts.
When you run catalina.sh stop, it starts up another jvm which also tries to bind to port 5005.
You need to move the debug args to the run and start arguments (in catalina.sh) of tomcat, putting them straight into the JAVA_OPTS is the cause of the issue you're having.
The problem is your tomcat is still running on the debug port(5005) or some other service running on the same port(5005).
If tomcat still running, you can kill it
if it in linux environment ps -ef|grep java, and identify the process id of it. and kill the process using sudo kill -9 .
If it in windows environment got to task manager and kill the tomcat and java process.
Now you should be able to start the server in debug mood without any prob.
This can happen on debugging unit test through the tool(eclipse) which has been executed through the maven. To sole this you can flow the same process.
First close the Eclipse and kill the java process as well and start it again.
This is due to both applications are listening the same port number i.e 8000 while running in debug mode.
One quick solution is change the debug port to 8001 in startup.bat
SET DEBUGPORT=8001
It seems that the port 5005 is already in use. Check open ports with netstat command.
This may be because you already opened tomcat. Check your processes.
It appears you are starting Tomcat with the Debugger enabled, This causes the JVM to attach to the Process for Debugging, However in the catalina.sh there is a case statement for start, stop, restart, so on and so forth. Issuing the stop command still adds this in as it is part of your Global JAVA_OPTS and tries to start the debugger listening on the same port for the shutdown command. If you remove the address=50005 from your JAVA_OPTS or use the start jdpa commands to start the VM with the debugger this will fix your problem.
Look at the default catalina.sh in the latest Tomcat distribution if you need a clean copy. It sounds like someone has made changes inside yours that are invalid and causing JDPA to run on start, stop, any command issued.
set JPDA_ADDRESS=8001 in catalina.bat i.e debug port
and change all 3 ports in server.xml
In my case (Tomcat installed form tarball) I had those debug options unintentionally set in my env. This fixed the error:
$ unset JAVA_OPTS