转载

技术问题总结(11.24)

这周写了好几篇关于OSB封装的服务，在客户端服务器消费的时候出现报文被截断的异常错误的问题分析文章，由于该问题出现概率不高，由于客户端有重试机制，也暂时不影响到具体的OSB服务运行和使用。虽然到现在为止，造成该问题的原因究竟是客户端服务器配置，负载均衡，网络，报文本身，OSB套件本身的Bug缺陷等哪方面还没有最终确认，但是整个问题排查和分析过程还是有意义的。

在问题排查和分析过程中，对于各类超时时间的含义，OSB的一些关键配置，报文解析，Http Post报文发送长短连接，Tomcat的一些配置都进行了了解，同时通过该问题的分析，也发现了在技术问题分析过程中的一些问题，供后面在分析问题中借鉴和参考。

1. 确定问题边界始终是最重要的

客户端发送报文到服务器端接收报文，当前现象是客户端Log日志报文是完整的，而OSB上Log的日志报文不完整，那么究竟是客户端，服务端，还是网络传输过程中出现的问题如何确定边界就相当重要。实际上在几天的问题分析和排查中对于问题边界一直没有最终确认，导致问题也一直没有很肯定的得到定位究竟在哪里，也导致最终问题没有得到明确的解决和排查。

比如这次出现的问题，实际上应该进一步确定边界。那么如何确定，就应该在客户端进行Http或TCP Trace，同时在服务器端也进行Http TCP Trace，通过两边的Trace信息才能够最终确定问题的边界在哪里。但是在生产环境我们很难这样去做，一个是并发量大，而且不止这一个接口服务在调用，一个是协调的需要配合的资源也太多，很难去联合排查和跟踪。

2. 问题复现很重要

在该问题的解决过程中，由于该异常是偶然出现，不定时而且是没有规律出现，这个也给我们排查问题造成了很大的麻烦。虽然在问题排查过程中，我将出现问题的异常日志，和前后正常的实例都进行了导出分析，对出现问题的服务器Server节点，调用方，调用时间段都进行了分析，但是没有明显的发现出现问题的规律究竟在哪里。

同时该问题具有很高的随机性，往往是第一次调用不成功，但是同样的报文在第二次或第三次就调用成功，同时每次对于报文的截断长度都不相同。这也导致我们很难分析具体什么场景下调用不成功。

即由于问题不能在特定的输入条件下重现，导致我们很难对问题进行进一步的分析和定位，也导致我们很难去进行特定的跟踪和边界确定。同时也很难在测试环境对该问题进行进一步的分析，和各种参数条件修改后的测试和验证。这些都导致问题很难快速的进行定位。

3. Oracle Support知识库和网上搜索很难搜索到完全一致的异常场景

在该问题的排查过程中，我们基本都Oracle Support网站进行了所有相关知识点的排查，同时选择各类关键字进行搜索引擎的搜索，其中包括了: Weblogic Tomcat Post Timeout KeepAlive 长连接超时 382030 Failed to parse XML text等，但是并没有搜索到完全一致的场景。

对于一个最相似的关于Failed to parse XML document的场景，我们进行了相关的调整，即将KeepAlive设置为False，同时对Post Timeout设置为120秒，但是仍然出现在120秒超时时间到达后任何没有Post到完整的请求而导致超时的问题。

由于无法搜索到完全类似的场景，也导致我们很难根据网上给出的方法进行进一步测试和验证。这也导致了问题迟迟不能得到有效的解决。而该问题对于Oracle顾问也只能给出进行Tcp Trace的无用建议。

4. 关键基础技术知识缺乏，导致问题分析和提出假设不合理，走弯路

在原来问题的分析和解决中，由于搜索引擎往往会给出完全类似的场景，我们只需要根据搜索引擎给出的排查思路对问题进行排查即可。因此解决起来效率很高，对于具体底层原理性的内容我们并不需要掌握和了解，只需要能够选择合适的关键字，通过搜索引擎搜索到最合适的内容然后进行排查即可。

但是这次问题，特殊点就在于搜索引擎根本无法给出完全类似的文章。这就导致我们要自己去提出各自合理的假设，并对假设进行逐一验证。那么如何提出合理的假设？这里就涉及到对于TCP底层协议，各个超时值的含义和原理，Tomcat Server的参数配置，OSB代理服务的解析过程，Weblogic的关键参数配置和含义，负载均衡策略，乃至Docker容器和IP映射等很多内容都有技术积累才可能提出最合理的思路。

比如在排查过程中，我会想到是否需要将Tomcat 的MaxPostSize值调大的假设，但是该异常是Tomcat向Weblogic Server进行Post请求发送数据，对于Tomcat 的MaxPostSize根本不会影响到这个Post请求，而只有Weblogic上的Post Size才会有影响。这个假设本身就不合理。而要快速的判断这些假设不合理，你就必须提前有这些关键的基础技术知识和背景积累。

包括对于Keep Alive长连接，Keep Alive的Time out超时时间设置是否会对该服务异常调用操作影响，实际上由于对Keep Alive长连接和各类Timeout的具体含义理解的并不深入，也使得很难判定究竟是否有影响，也只能是注意尝试去排除可能性，这些也都导致了很难快速的定位出问题根源究竟在哪里。

5. 涉及到外围干系人协同的时候，导致排除困难

这个也是解决服务接口问题的一个关键影响。对于接口服务运行问题，往往涉及到业务系统消费方，业务系统提供方，OSB服务总线，网络，负载均衡设备等多个相关因素和厂商。对于一个问题的排查往往需要协调多方的资源在约定的时间相互配合才能够完成，这些都直接导致排查难度很大，很难依靠个人一方力量就完成。

在原来类似大项目实施过程中，也经常会遇到这些接口问题的分析和排查，往往也都是问题造成严重影响后，各方才会真正重视该问题，并各自协调资源形成联合的问题排查团队进行问题分析和排查，最终才能够解决问题。

虽然截止现在问题没有得到最终解决，但是整个分析过程仍然有意义，特进行本文总结。

原文 http://blog.sina.com.cn/s/blog_493a84550102yhzv.html

正文到此结束