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.
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.