I have a java app running on a server (linux) whose ip is 10.7.185.168:8123, using this command.
java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:8123 OurApplication
and I try to debug it from another machine (windows) with:
jdb -connect com.sun.jdi.SocketAttach:hostname=10.7.185.168,port=8123 -dbgtrace 0x00ffffff
but this results in the following stacktrace
java.io.IOException
at jdk.jdi/com.sun.tools.jdi.VirtualMachineManagerImpl.createVirtualMachine(VirtualMachineManagerImpl.java:238)
at jdk.jdi/com.sun.tools.jdi.VirtualMachineManagerImpl.createVirtualMachine(VirtualMachineManagerImpl.java:245)
at jdk.jdi/com.sun.tools.jdi.GenericAttachingConnector.attach(GenericAttachingConnector.java:120)
at jdk.jdi/com.sun.tools.jdi.SocketAttachingConnector.attach(SocketAttachingConnector.java:83)
at jdk.jdi/com.sun.tools.example.debug.tty.VMConnection.attachTarget(VMConnection.java:519)
at jdk.jdi/com.sun.tools.example.debug.tty.VMConnection.open(VMConnection.java:328)
at jdk.jdi/com.sun.tools.example.debug.tty.Env.init(Env.java:63)
at jdk.jdi/com.sun.tools.example.debug.tty.TTY.main(TTY.java:1087)
I've seen reference to IO exception in other threads talking about failed handshakes but that doesn't seem to be the case here.
- I can ping the linux server and even connect to a "nc -l" request with Curl so I dont think its a firewall issue.
- if I netstat -tulpna | grep 8123 on the server it says that a connection was ESTABLISHED, but obviously it didn't make it back to me.
- Both my local machine and the server are running JDK 11.
Any ideas?
As a follow up to this question. I discovered with my team that a firewall TCP rule seemed to be the culprit. Simply put, the TCP packets for java debugging were too large and were automatically getting intercepted by my company's firewall. Packets for pinging and connecting via NC unix command were small enough to connect with no issue. I eventually settled on an alternative means to debug my code.