技术问题分析-超时02(10.25)

接昨天的分析。首先昨天分析了在600秒出现线程阻塞和挂起的时候，再等待了900秒出现连接超时，因此从时间上看是1500秒超时。为了印证这个假设，我们将Read Time out的时间修改为400秒，那么就应该是1300秒报出服务超时的异常错误，但是最终测试的结果仍然是1500秒超时。

对于该超时，在OSB集群侧没有任何5分钟超时的设置，而检查F5负载均衡的超时配置文档可以看到，F5负载均衡设备上有一个idle time out的超时设置，默认就是300秒。因此为了解决该问题，首先还是要确定是否和负载均衡设备有关系。

对于当前的服务调用，需要通过经过ESB服务集群，业务系统的服务集群，才能够完成。如下：

即整个服务请求的调用过程是为1->2->3->4的顺序，需要同时经过1和3两个负载均衡设备。那么整个服务调用超时就和1,2,3,4四个节点的配置都会相关。因此为了进一步进行验证，我们尝试对如下路径直接调用以排查问题。

1. 不走业务系统的负载均衡 1-2-4路径调用

在该模式下通过管控系统和通过SOAPUI分别进行调用测试。发现整体调用能够成功，有成功的实例返回。对于通过管控调用的时候会出现有重试的现象，但是通过SOAPUI调用的时候没有发现重试。

其次对于客户端调用仍然会出现5分钟调用超时，返回Connection Reset的错误。但是这个时候实际上服务仍然还运行，即2-4的连接仍然在运行并能够成功运行完，因此可以看到成功的服务运行实例数据。

2. 不走ESB和业务系统两边的集群，走2-4直接进行接口服务调用。

在该模式下，我们通过SOAPUI对接口服务进行调用测试，能够成功调用，有成功的实例返回，同时对于客户端也可能得到成功的返回信息。即既有成功的实例，客户端也返回成功。即我们希望达到的一个结果。

3. 走两边的集群模式 1-2-3-4路径进行调用

这个即是最初的调用模式，我们还是使用SOAPUI进行调用，发现会出现调用重试，同时最终服务运行失败，报1500秒的超时错误。在客户端也会报出连接超时错误。即和我们最初看的现象是一致的。但是具体为何会发起5分钟后的重试，以及是否该重试是由负载均衡设备发起的暂时不明确。

在负载均衡上面，我们看到有tcp_tw_recycle参数配置，但是暂时不确定自动触发重试是否和该参数的设置有关系，从网上文章来看是不建议对该参数配置进行启用。

参考： http://www.cnblogs.com/jdonson/p/4760080.html

该超时问题经过分析，基本确定是负载均衡的超时设置引起的，因此解决就简单的，即对两个集群对应的负载均衡超时设置都进行调整，同时确保该超时时间>OSB服务配置中的Read Time out时间即可。