JDB -connect IO.Execption 沒有消息

Question

我有一個 java 應用程序在服務器 (linux) 上運行，其 ip 是 10.7.185.168:8123，使用此命令。

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:8123 OurApplication

我嘗試從另一台機器（windows）調試它：

jdb -connect com.sun.jdi.SocketAttach:hostname=10.7.185.168,port=8123 -dbgtrace 0x00ffffff

但這會導致以下堆棧跟蹤

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)

我在其他討論握手失敗的線程中看到了對 IO 異常的引用，但這里似乎並非如此。

• 我可以 ping linux 服務器，甚至可以連接到 Curl 的“nc -l”請求，所以我認為這不是防火牆問題。
• 如果我.netstat -tulpna | 服務器上的 grep 8123 表示已建立連接，但顯然它沒有返回給我。
• 我的本地機器和服務器都在運行 JDK 11。

有任何想法嗎？

Answer 1

作為這個問題的后續行動。 我和我的團隊一起發現防火牆 TCP 規則似乎是罪魁禍首。 簡單來說，java調試的TCP數據包太大，被我公司的防火牆自動攔截了。 通過 NC unix 命令進行 ping 和連接的數據包足夠小，可以毫無問題地進行連接。 我最終選擇了一種替代方法來調試我的代碼。