I have a few services set up in the SPring config to use RMI to invoke methods. In the test environment this resolves to the localhost, which could potentially allow me to debug the code. Unfortunately, it simply exectures the method and returns a value. Is there a way to setup intellij to debug RMI localhost requests?
What a problem to debug Spring RMI service? If you run it in Tomcat, just start tomcat as catalina.sh jpda run and in Idea create Remote Debug configuration, transport - socket, debugger mode - attach, host - localhost, port - usually 8000. That's all.
Related
My understanding is that tomcat server can be accessed thru jmxrmi if we configure following properties. Port can also be configured.
-Dcom.sun.management.jmxremote.port=30000
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.password.file=xyz
-Dcom.sun.management.jmxremote.access.file=xyz
After that tomcat server can be connected thru some jmx tools like jconsole or jvisualvm etc. But I also noticed that same tomcat server can also be connected on default jmxrmi port 1099. I havent configured anywhere port 1099. Even though if I comment out all above properties, I see tomcat still can be connected to on port 1099 on jvisualvm.
Please suggest, what might be enabling this connectivity on default port. And how can I disable this connectivity?
Possibly some other third party libraries in classpath might be doing it, but how to figure which one?
JMX uses two ports: one for the JMX connection (which you have set to port 30000) and another one for RMI communications. Java defaults to port 1099, but if it's in use, it will choose the first port available after 1099. In Java 8, you cannot explicitly set this port via system properties.
For later Java versions, you can use the system property com.sun.management.jmxremote.rmi.port.
Tomcat has a workaround for this. You can use the JmxRemoteLifecycleListener to set the rmiServerPortPlatform attribute. Set that to whatever port you prefer.
Note that you cannot disable this second port: it is required for JMX to operate properly.
I have successfully implemented my remote debugging for Spring boot applications in tomcat server for several times.
To make remote debug enable in tomcat server just need to change in catalina.sh and set: JAVA_OPTS="$JAVA_OPTS -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=9999 $JSSE_OPTS"
And start tomcat by catalina.sh jpda start
But I need to know how it works internally through this specific port over TCP network connection from IDE?
I'm trying to enable JMX on tomcat docker image using docker-compose.yml but I'm still getting error that VisualVM cannot connect to the JMX.
tomcat:
image: tomcat:8.0-jre8
environment:
CATALINA_OPTS: -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
ports:
- "9000:9000"
JMX requires more than just a single port since RMI is also involved. Remote JMX is always a challenge with Tomcat, and using Docker basically makes this "remote" access.
Have a look at Tomcat's JMX Remote Lifecycle Listener to see the port numbers that can be set, and use that listener to set them. If you don't, the RMI server is basically free to use whatever ports it wants to use and you can't predict them.
Once you set those ports, give the port mapping to Docker and you should be good to go.
I'm attempting to connect to a remote JMX service using VisualVM 1.3.8 with JRE 1.8.0. Making exactly the same connection with JConsole works perfectly, however the attempt to use the same parameters with VVM just hangs at the 'Adding services' stage. I've looked in the VVM log but there is literally nothing logged.
I also read here at the VVM remote JMX doc:
Note: To retrieve and display information on applications running on the remote host, the jstatd utility needs to be running on the remote host.
That puzzles me since I can make the remote JMX connection using JConsole and as far as I can tell, jstatd is not running on the remote.
Does anyone know if jstatd a requirement only for VVM as a remote JMX client? As the JMX connection can be made with JConsole between the same client and server endpoints, then there's no problem with network/firewall etc.
Other than that I'm really puzzled where else to look for clues?
I had the same trouble when I switched from Java 7 to 8, while using SOCKS where I was updating proxy settings through VisualVM -> Tools -> Plugins -> Settings -> Proxy Settings. However, I have been successful with the following:
Run your JVM with the following options:
-Dcom.sun.management.jmxremote.port=<JMX_PORT>
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
Note that you could obviously do something more secure, both w.r.t SSL and authentication.
Setup a SOCKS proxy from your localhost to the remote server:
ssh -D<SOCKS_PORT> -vvv -N <REMOTE_HOST>
Run either of these commands on your localhost:
jconsole -J-DsocksProxyHost=localhost -J-DsocksProxyPort=<SOCKS_PORT> service:jmx:rmi:///jndi/rmi://<REMOTE_HOST:JMX_PORT>/jmxrmi
jvisualvm -J-DsocksProxyHost=localhost -J-DsocksProxyPort=<SOCKS_PORT> --openjmx <REMOTE_HOST>
I need to debug a Java application using remote debugger via an SSH tunnel. I configured putty on my PC and I'm able to connect to any other service running on the server using tunnel however eclipse remote debugger fails to connect.
On the server side I use Java 1.6.0_21-b06 started with following debug options:
-Xrunjdwp:transport=dt_socket,address=8686,server=y,suspend=n
On my laptop ssh tunnel is configured as:
L8686 IP_ADDR:8686
Are there any limitations for JVM debugger when running session over ssh tunnel?
One more thing, when I try to connect, on the server console I can see following log mesage:
Listening for transport dt_socket at address: 8686
I have the same scenario and everything is working fine, here is how I run my java app:
java -Xmx120m -agentlib:jdwp=transport=dt_socket,server=y,address=8000 -jar bla.jar
probably the most relevant part is the -agentlib one.
Can you try L8686 localhost:8686 instead, as the JVM may be refusing connections from non-local addresses? Note that 'localhost' is the address from the server's point of view.
That Listening for transport dt_socket at address: 8686 usually occurs if the VM is started or an existing debug session is closed and the VM starts listening for a debug connection again. Maybe running tcpdump on the server could give a clue which peer closes the connection and look a bit deeper on that side.