微服务调用出现低概率 连接超时io.netty.channel.ConnectTimeoutException，状态码490，服务端未收到请求。

[lengshanwudi]

--- 上图为metric日志报错截图。

定位过程：
1、观察到客户端请求失败，查看interfacelog，发现错误码为490；客户端运行无明显运行异常日志
2、查看服务端运行日志，无任何异常信息，服务端未收到请求，时间点前后无任何异常日志打印。
3、查看metric日志，见上面截图，RestClientInvocation:]|Failed to send request, local:not connected, remote:/10.33.8.46:8082.
io.netty.channel.ConnectTimeoutException: connection timed out: /10.33.8.46:8082
4、观察服务端出现问题时间点前后日志，服务可以正常收到来自上述客户端的请求，并能处理成功。

以上，请专家帮忙指点可能是哪里问题？观察过自测环境和现网，均有低概率发生。十分感谢~

[liubao68]

看 metrics 日志系统负载并不高。在网络负载不高的情况下， connect timeout 有可能是网络不稳定导致的。

[yhs0092]

除了二楼给出的可能性，还有一种可能是 consumer 端和 provider 端的连接超时配置没配好，HTTP1.1 长连接复用场景下 consumer 端准备复用长连接发请求时 provider 端判定连接 idle timeout 主动断连，导致网络发送失败。
具体原因可以考虑 tcpdump 抓包分析，以下是我说的这种可能性的修复方法：

• consumer业务调用超时时间：servicecomb.request.timeout
• client端网络连接 idle timeout：servicecomb.rest.client.connection.idleTimeoutInSeconds
• server端网络连接 idle timeout：servicecomb.rest.server.connection.idleTimeoutInSeconds

实际使用的时候注意配置 consumer业务调用超时时间 < client端网络连接 idle timeout < server端网络连接 idle timeout。此时连接超时断连也是 client 端主动发起的，这样才能确保 consumer 调用 provider 时不会出现 client 端尝试复用的HTTP连接恰好被 server 端超时断开的情况，进而导致请求调用失败。
至于这三个配置项之间间隔多少，建议自己摸索一下，保险一点的可以设置 10 秒以上（随口估计的，不保证没问题 : )）。

参考：

• Consumer的通用配置项
• REST over Vertx
• REST Transport Client 配置项

注意：以上说明适用于 Rest over Vertx 传输方式，HTTP1.1 的场景，如果使用的是 HTTP2，或者server端传输方式选择的是 REST over Servlet，就请结合实际分析配置。

[dengxiafubi]

长连接复用导致的问题一般是connection was closed

[liubao68]

close old issues, please feel free to submit a new one if the problem still exists.