ywxzm03 commented on issue #1073: URL: https://github.com/apache/dubbo-go-samples/issues/1073#issuecomment-4390667664
## 结论 我这边重新排查后，当前判断该问题与 VPN / 隧道网卡影响 Dubbo Java 本机地址选择有关，不是 Java generic -> Go generic 的兼容性等问题 ## 测试环境 - dubbo-go-samples 的 Go 依赖通过 go.mod replace 指向本地 dubbo-go-3.3.2 - Java 环境：JDK 17 ## 复现现象 开启 VPN 时，Java client -> Go server 失败： ```text Passed: 0, Failed: 10, Total: 10 ``` Dubbo Java 日志中 `current host` 为 VPN/隧道网卡地址： ```text current host: 198.18.0.1 ``` Netty 连接日志中实际远端地址也异常： ```text R:/198.18.0.1:50052 ``` 但 Java client 配置的直连地址是： ```text tri://127.0.0.1:50052 ``` 此时 Go server 侧没有进入 provider 方法的业务日志。 ## 验证结果 关闭 VPN 后，未修改 Java client、Go server、接口定义、`User` 结构和启动参数，Java client -> Go server 可以正常通过： ```text current host: 10.134.92.16 ``` ```text Passed: 10, Failed: 0, Total: 10 ``` 开启 VPN 时，如果显式忽略 macOS `utun` 网卡，也可以通过以下方法进行规避： ```bash MAVEN_OPTS="-Ddubbo.network.interface.ignored=utun.*" \ mvn clean compile exec:java -Dexec.mainClass="org.apache.dubbo.samples.ApiTripleConsumer" ``` Windows 下如果存在 WSL / Hyper-V / Docker / VPN / Wintun / TAP / vEthernet 等虚拟网卡，也可以通过以下方法进行规避： ```text dubbo.network.interface.ignored dubbo.network.interface.preferred ``` ## 对建议排查方向的结论 - Java generic client 与 Go generic server 在当前 sample 覆盖的调用场景下可以互通 - Hessian / generic invocation 编解码链路可以正常工作 - `User.time.Time` 仍是跨语言样例中的潜在风险点，但不是本次 `DEADLINE_EXCEEDED` 的直接原因 - JDK 17+ 下的 `InaccessibleObjectException` 属于 hessian-lite 反射访问噪音，不是主因 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
