技术问题分析-报文截断02(11.21)

今天继续分析下Oracle OSB总线代理后发布的Web Service服务，在客户端消费的时候出现ESB系统级的异常，具体的异常错误信息为：

OSB-382030:Failure while un-marshalling message: Failed to parse XML text

该问题继续排查了一整天，但是仍然没有得到确切的原因。今天的进展如下：

发现出现异常的消费端均没有采用Http Chunked编码模式，这个时候Server端在获取完整数据的时候，需要和http-header中传递的Content-Length做比较，如果长度不一致也会抛出异常。在前面我们分析了当前的Post Timeout设置为2分钟，即在2分钟内如果还没有获取到完整的报文信息，那么就会出现Post Timeout的超时错误。而根据实际的日志排查，基本分析为：

OSB在接收消息请求的时候，在2分钟没有接收到完整的消息，导致出现Post TimeOut，而这个时候未完整的消息流传递给Proxy代理服务的时候，由于XML报文不完整，导致报出parse XML text的错误。

同时在设置Http的设置中，除了Post Timeout，还有一个Duration持续时间的设置（关闭不活动的http连接需要等待的时间），当前时间设置为30秒，是否该值也需要调整到120秒？这个是一个疑问点。

可以想到的后续进一步解决思路有

1. 对于出现问题的消费端，修改为启用Http Chunked编码模式方式。

2. 修改Duration持续时间的设置

这两个都是可以尝试去分析和解决的方向。

其次，今天我们进一步抓取了OSB Server上的日志信息，对于osb server本身的日志并没有太多的异常记录。但是我们在观察access.log日志的时候发现，在OSB Server上可能只产生了5个服务调用实例，但是在access.log文件里面却有多条Post记录，而每条记录本身都只Post传输了一部分数据，基本在1k左右。其中大量的Post都是在1059byte，初步分析应该是一次接口服务调用对于消息数据的传递分为多次Post进行，每次post只是传输了一部分数据。

而最后需要Server端对所有数据进行汇总后形成完整的报文信息再去调用代理服务。

那么为什么消费端会产生如此多次的Post调用记录？而其它消费方系统却没有这个现象，经过分析，出现问题的两个消费方系统均采用了 Docker 容器进行部署，分配的是动态IP信息，是否存在可能每次Post过来的数据本身也分散到多个节点在传输？

如果这个假设成立的话，那么完全就有可能是一次完整的Post操作被负载均衡到多个OSB Server节点上，从而导致了报文信息不全。因为当前我们的的负载均衡策略是完全轮询，不保持会话，对于非Docker部署的时候不会出现问题，但是在Docker动态容器化部署的时候则出现问题。

因此可以进一步验证的是将集群修改为Session会话保持后，是否还存在一样的问题。