fail to respond 异常

问题现象：

调用方通过平台调用数据服务，出现fail to respond 报错信息，频率大概每周出现2-5次，不规律。

问题分析：

根据堆栈信息分析，HttpClient源码中代码行。根据堆栈信息排查到：org/apache/http/impl/conn/DefaultHttpResponseParser.java

DefaultHttpResponseParser继承了AbstractMessageParser，读取解析HTTP响应的头部行时候，parseHead方法读取sessionBuffer，若该数据为空则抛出NoHttpResponseException。而HttpClient则继续用这个连接发送请求则会读取不到正常的response，因而抛出NoHttpResponseException。

数据服务对应的keepalive_timeout=0，每个请求后会立即关闭连接。0代表什么意思呢？

数据服务主要是安全和隐私方面，这方面要求高的会禁用持久连接确保每个请求后立即关闭连接，减少被利用的风险。客户端某一时刻请求量大的时候，会复用连接池里面的连接。在客户端HttpClient连接空闲时间（10s）检查内，HttpClient客户端从连接池中获取的连接已经失效。

问题原因

目标服务器负载太高处理不过来因而断开了连接，目前是可以排查排除网关及上游服务压力过大原因。

数据服务每个请求后会立即关闭连接，某一时刻请求量大于连接池的最大连接个数，HttpClient客户端从连接池中的连接已经失效，请求导致出问题。

解决方法：

1. 优化SDK连接池配置--不能从根本上解决，只能减少概率。
   1. 缩短setValidateAfterInactivity，连接空闲多长时间（单位：毫秒）进行检查。超过该时间的连接，每次从池中获取，会进行校验（读取socket），校验失败会重新获取连接。默认2000ms，SDK里面配置10s。时间越短越不容易拿到过期的连接。
   2. 开启HttpClientBuilder的evictExpiredConnections，evictIdleConnections方法，是定时任务定时扫描，清理过期，空闲的连接。
2. 调整数据服务的Nginx配置keepalive_timeout 为60s。
3. 调用方配置重试（HttpClient默认是打开自动重试的）。但默认是一共重试3次。如果连接池里是5条连接，全部过期。那么还是会出现异常（概率比较小）。另一个方案是配置重试次数> 连接池里单个route的最大连接数量，保证连接池里的连接全部失效后，建立新连接。
4. 平台提供一套不用HttpClient连接池的方法供调用数据服务的业务使用。或者调用方自己去定义Client。