So i was going to debug my Solr filter plugins on Intellij Community Edition. After i ran the program from comand prompt with this command
java -jar start.jar -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8983
I started my Intellij debugger with this config:
Transport : socket
Debugger mode : attach
Host : localhost
Port : 8983
But when I ran the debugger I got this error:
Error running Debugger: Unable to open debugger port (localhost:8983):
java.io.IOException "handshake failed - connection prematurally closed"
Any idea how to fix this?
I got that error when trying to access to debug port on a Docker container.
If you are trying to access the debug port inside a Docker container make sure you are specifying the port as *:5005
E.g.
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005
This has been changes since Java 9.
See: REGRESSION: Remote debugging does not work on JDK 9
It's not a bug. It's a security.
Before the JDK-8041435
If you have a server with EXT and INT interfaces and start Java process with address=5900 it binds to both interfaces and allow anybody from entire world to connect to your java process unless you block it on firewall.
After JDK-8041435 socket transport try to guess localhost and bind to localhost only. I.e. socket transport by default works only if both client and server are located on the same machine. It's not an easy task to guess proper localhost. so ever same-machine configuration might not work in some situation because of network setup.
You can restore old, insecure behavior using * (asteric)
i.e.
-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:5900
should work exactly as it was before JDK-8041435
But it's recommended to explicitly specify ip address to bind when it possible.
And JDWP socket connector accept only local connections by default
The JDWP socket connector has been changed to bind to localhost only if no ip address or hostname is specified on the agent command line. A hostname of asterisk (*) may be used to achieve the old behavior which is to bind the JDWP socket connector to all available interfaces; this is not secure and not recommended.
It should be something like this,
java "-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8983" -jar start.jar
it's working now
I had this error with OpenJDK 11 inside Docker container and setting environment variable JAVA_DEBUG_PORT to "*:5005" worked for me.
You forgot to specify -Xdebug on the java command line.
Edit: As in
java -jar start.jar -Xdebug -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8983
It has helped me, at least in Intellij IDEA:
java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=0.0.0.0:5005
try to add ip 0.0.0.0.
Related
I have application deployed on tomcat 8.5.63 version and Java 1.8 version. Whenever I am deploying the application tomcat is opening up tcp port 1099 for JMX rmi by default. And to which I am able to connect without any authentication from remote client using jvisualvm tool. I don't want that port to get opened up by default. I have tried changing the various jvm arguments based on other solution in SO but no luck.
Given below are the recent configuration which I have tried.
CATALINA_OPTS="-Xms512m -Xmx1024m -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=16105 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.login.config=Tomcat -Djava.security.auth.login.config=$CATALINA_HOME/login.config -Dcom.sun.management.jmxremote.access.file=$CATALINA_BASE/conf/jmxremote.access -Dcom.sun.management.jmxremote.rmi.port=16106
I have specifically mentioned the -Dcom.sun.management.jmxremote.rmi.port=16106 to be used for JMX rmi but not able to understand why it still listening to port 1099. Please advise.
Note: I did saw some answers mentioning to pass XX:+DisableAttachMechanism as jvm argument to block jxm. But what if we want to have have jxm also enabled and default port(1099) should not be used.
I'm trying to connect JVisualVM, running on my local machine, to a remote machine which is running a WildFly server (version 8.1.0, to be specific.)
I didn't configure the WildFly server myself, and I don't know who did, but I do know that I can log in as an administrative user from my local machine by pointing my browser at:
https://[ip address of the remote machine]:9443/console
Note that it's https, not ordinary http, and that the port for that has been set to 9443 (I think the default is 8080 or 9990 or something... IDK, I saw a lot of port numbers online. I have been explicitly told that http was disabled for this WildFly server).
I can SSH into the remote machine. I can navigate to the bin directory for WildFly and run jboss-client.sh. I have to connect on port 9999 (I think the default is 9990 for that?)
I copied the jboss-client.jar (under bin/client) to my local machine and ran JVisualVM from the command line like this:
.\jvisualvm.exe -cp:a C:\[path to]\jboss-client.jar
It launches fine. File > Add Remote Host: Then I entered the IP. OK. I right clicked on it under Remote in the tree and picked Add JMX Connection. I entered
service:jmx:http-remoting-jmx://[ip]:9999
I checked off that I wanted to use the security credentials and entered the username and password. Checked off to save the security credentials. Left "Do not require SSL Connection" unchecked. Hit OK. It immediately spat out the message
Cannot connect to admin#service:jmx:http-remoting-jmx://[ip]:9999 using service:jmx:http-remoting-jmx://[ip]:9999
I also tried the port 9443, 9990, and 8080 instead. None of those worked. I tried https instead of http in the protocol name. That also didn't work.
What am I missing? How is it that I can access the console, and connect with jboss-client.sh, but I can't use JVisualVM? Is there some log I can use somewhere to see what's wrong? Maybe someone can point out a configuration I've missed somewhere?
Not sure if it's important or not, but my local machine is running Windows 10 with JDK8 installed. The WildFly server is using Java 6 on CentOS 6.3.
You need to add the jboss-client.jar (or jboss-cli-client.jar) to the class path for JVisualVM. The library can be found in the bin/client directory of the WildFly install.
I used the following command to add the library to the class path.
jvisualvm --cp:a ~/servers/wildfly-10.0.0.Final/bin/client/jboss-client.jar
Then I used service:jmx:remote+http://[ip]:[port] and was able to connect.
I don't know if someone else is also (still) having the same issue (Wildfly10 on a remote machine where management console is available at 9443 with HTTPS). The following worked for me.
For ssh connections:
Starting jvisualvm with jboss-client.jar
jvisualvm --cp:a #JBOSS_HOME/bin/client/jboss-client.jar
Using the following connection string:
service:jmx:remote+https://remote-server:9443
NOTE: I used here remote+https
Provide username and password
Hope this helps.
you missed run jstatd command in remote host ,
this little program is RMI server that possible connection from client to remote host though you using jmx connection it used jmxrmi protocol for that connection .
so first in remote host create file name as security.policy with this contain :
grant codebase "file:${java.home}/../lib/tools.jar" {
permission java.security.AllPermission;
};
off course you must in file section for linux put explicit path and then of creation this file put it in bin directory of jdk.home
then you should run this command on remote host
$JAVA_HOME/bin/jstatd -J-Djava.security.policy=path of /security.policy -J-Djava.rmi.server.hostname=remote ip address -J-Djava.net.preferIPv4Stack=true
then you could connect to server off course with correct settings.
Include jboss-cli-client.jar and jboss-client.jar under \lib\visualvm\platform\lib and restart jvisualvm to pickup new jars.
I want to remote debug an application running in Tomcat 7. Tomcat is running as a service on a Win2008 server.
I added the following to the Java options in the Java Configuration Panel of Tomcat:
-Xdebug -Xrunjdwp:transport=dt_socket,address=4711,server=y,suspend=n and opened the firewall on my workstation and the server for this port.
But when I try debugging from IntelliJ 9 on my workstation, I get an error message Unable to open debugger port : java.net.ConnectException "Connection timed out: connect". The jvm is the standatd Sun/Oracle 64 bit JVM version 1.6.0_27.
I verified that the command line parameters are in use by accessing ManagementFactory.getRuntimeMXBean().getInputArguments() within the application deployed to Tomcat and logging the result to the log file.
I verified via Wireshark on my workstation and on the server that the TCP request on port 4711 is sent from my pc and arriving on the server, but there is is no answer. Running netstat -a on the server does not show a process listening on this port. So I assume somehow Tomcat/JVM does not start the remote debugging.
You need to put -Xdebug and -Xrunjdwp... on separate lines in the Java panel of the Tomcat Service Configuration Panel.
So having:
-Xdebug -Xrunjdwp:transport=dt_socket,address=4711,server=y,suspend=n
will not work, but:
-Xdebug
-Xrunjdwp:transport=dt_socket,address=4711,server=y,suspend=n
will.
I'm hoping to get some help with this weird problem. We're running the Jacorb name server and I have a simple client that I'm using to try to connect and do awesome CORBA voodoo. The name server is running, but when I try to start my java app, I get a "Connection failure" error (org.omg.CORBA.COMM_FAILURE, minor code 201, "caused by java.net.ConnectionException: Connection refused: connect").
Here's the weird part. The error reports that it's trying to connect using the default port 900, but I'm passing in an argument to try to override the port number of the name service to match the one being used by the name server. My java command is like this:
java -classpath . HelloClient -Djava.endorsed.dirs="bla bla bla" <br>
-Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB
-Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton
-DORBInitRef.NameService=corbaloc::localhost:2809/StandardNS/NameServer-POA/_root
I also tried the parameters without the first capital D (I've seen it both ways and I don't know the difference).
Now, if I put in -ORBInitialPort 2809, then the client does appear to try to connect, but then I get a corba.OBJECT_NOT_EXIST error.
I could use any help or advice anyone has.
Connection Refused. This sounds like a firewall/program not running issue.
try a telnet <machine> 2809. You should get a "Connected to "
and not a refusal, if everything is running/enabled correctly.
I'm running on a UNIX client so the paths use UNIX style.
jacORB installed properly ? e.g. get the nameservice entry from the
orb.properties file (in ${JAVA_HOME}/jre/lib/
I use "ORBInitRef.NameService=corbaloc::localhost:2809/NameServer"
as "NameServer" is used on the production name server and not the other
string of "Standard...."
The other changes in the properties files are setting the paths to UNIX
style (i.e. e:\NS_Ref -> /tmp/NS_Ref)
jacorb.naming.ior_filename=/tmp/NS_Ref
1a. Setting the http:// in the properties file didn't seem to do anything
in regards to resolving on the client side.
1b. NOTE: start ns with:
ns -DOAPort=2809
Log will show:
2010-05-27 10:00:47.777 FINE Created socket listener on 0.0.0.0/0.0.0.0:2809
2010-05-27 10:00:47.777 FINE Using port 2809
Running:
$ lsof | grep 2809
java 27529 jbsymolo 15u IPv6 693300 TCP *:2809 (LISTEN)
$ lsof -Pnl +M -i6
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
Naming_Se 9678 1000 7u IPv6 45779 TCP *:51148 (LISTEN)
java 27959 1000 15u IPv6 696092 TCP *:2809 (LISTEN)
Not Running: (shows nothing)
ns when started will log where it reads the properties from and it shouldn't
throw any errors. If it does your properties files have issues.
VM arguments. The -D is used to set system properties. Any Java code can
then access any property so defined via System.getProperty(). Even though
I've also seen the "non-D" used, I've been using the D.
-DORBInitRef.NameService=corbaloc::localhost:2809/NameService
-Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB
-Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton
When running the client in Eclipse, I see the following in the Console:
May 27, 2010 10:01:06 AM org.jacorb.config.JacORBConfiguration init
INFO: base configuration loaded from file /usr/lib/java/jdk1.6.0_18/jre/lib/orb.properties
...
2010-05-27 10:01:09.836 FINE Trying to connect to 127.0.0.1:2809 with timeout=90000.
2010-05-27 10:01:09.844 INFO Connected to 127.0.0.1:2809 from local port 45745
2010-05-27 10:01:09.846 FINE wrote 12 bytes to 127.0.0.1:2809
...
Skipping lots of other read/write traffic
I can't be sure without seeing the rest of the code, but I'm pretty sure you need to change the InitRef string to be:
-DORBInitRef.NameService=corbaloc::localhost:2809
When your client connects, this should give you the root naming context for the naming service and then you can traverse the NameContext tree to get to your desired server object.
I'm working on a Java 10 application that uses an embedded Jetty server to provide control from a local network, and I'm attempting to connect to the JVM and failing. It's running on Ubuntu 18.04 LTS desktop.
My startup script has the following lines:
java -Xdebug -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n -Djava.library_path=${LIB_PATH} -classpath ${CP} -jar ${APP_DIR}/app.jar
I have ufw on the system, and I've verified that the port is open. My output from ufw status includes:
8000 ALLOW Anywhere
8000 (v6) ALLOW Anywhere
In IntelliJ, my debug configuration is
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000
When I try to connect, I get an error message that the connection is refused.
with the IP of the machine in the config's address box.
Looking at the output of netstat -l, I see the following:
tcp 0 0 localhost:8000 0.0.0.0:* LISTEN
Does this mean that the debugger is only listening for connection on the localhost? Do I need to do something to have it listen on a network?
So I found the answer fairly quick. I needed to modify the line I use for the server so that it reads:
java -Xdebug -agentlib:jdwp=transport=dt_socket,address=*:8000,server=y,suspend=n -Djava.library_path=${LIB_PATH} -classpath ${CP} -jar ${APP_DIR}/app.jar
So that is listens on all interfaces.