转载

技术问题分析05(4.19)

首先记录下最近做的修改的情况

1. 由于OSB服务运行后台日志有报错，插入Log日志的数据的时候出现超长而无法正常插入，我们开始的解决思路是把Oracle的系统表的Error_Reason和Error_Detail两个字段的长度调整到了4000，但是仍然报错。后面的解决思路是直接将Oracle的服务日志先禁用掉。

2. 回顾下问题出现的顺序情况，最初整个环境是正常的，但是收到反馈有JMS分省分发的WS服务接口响应缓慢和超时。而当时收到这个信息后我们没有马上去校验是否所有Server节点都有问题，因为当时出现的情况是不分省分发的服务正常，只有分省分发的服务缓慢。

因此初步思路是检查分省分发逻辑，发现分省分发的场景需要动态建立JMS连接，而通过Debug发现这块的响应相对缓慢导致服务调用超时。因此对这部分逻辑在OSB控制台上的部署模板上直接修改。

在这个修改完成后，发现管控台服务进行服务部署，在进行服务部署的时候出现500错误。

接着就是去查找500错误的原因，这个原因实际上查找起来也相对困难，在网上也搜索了很多方法进行验证，但是最终并没有解决掉该问题。

3. 在后台日志中发现了30秒超时的问题，而我们实际的服务部署超时是3分钟，考虑到将Weblogic Http Post等几个超时时间设置增加到60秒到120秒。在进行了该修改后，某天上午部署正常，但是再修改到30秒后部署报错。奇怪的是修改回60秒也部署报错。

而在出现500错误，伴随出现了Session占有或Session会话激活需要重启Server的异常错误。而接着有出现了JMS分发服务出现调用超时的错误。即：

4. 对于Cluster环境，再调用JMS分发服务进行JMS消息分发的时候，出现由两个JMS节点分发出现异常，一个JMS节点正常。当时出现的场景是当OSB Server和JMS Server在一台服务器上面的时候正常，而不在一台服务器上面的时候出现异常。而JMS消息分发本身封装为了服务，并不是服务本身封装慢，而是在建立初始化JMS上下文和建立JMS会话的时候缓慢，同时还导致了JMS分发服务超时。该问题暂时也无法解决，只有停掉了两个节点。

在停掉了两个JMS节点后，JMS分发服务正常，其它WS服务也正常。但是对于服务部署仍然是存在500错误和Session占有错误。同时发现一旦Session占有就无法再进行部署，往往需要对整个Server重启才能够进行部署。

5. 对于Session占有，尝试了在部署的时候对于管控台不登录，对于部署管控平台也只一台机登录，但是该情况往往仍然存在。同时发生Session占有的情况都是在部署出现500错误或超时服务后。

检查代码，对于通过JMX进行自动化部署的代码，在出现异常后，我们进行了DiscardSession操作，但是在DiscardSession这个操作本身又出现异常，导致了Session根本没有释放掉，同时在Session没有在超时自动过期的情况下我们又去调用部署，所以导致Session占用。

而这个时候，问题衍生为两个子问题需要进一步分析和处理，即：

5.1 如何在部署出现异常的时候能够成功释放Session，当前Session无法释放是否是Session本身已经超时，所有无法正常释放掉，还是说出现了类似Lock的场景。

5.2 在出现部署异常的时候，是否可以到SB Console控制台对Session进行手工释放。

6. 对于SOAP的报文，如果XSD文件结构中对于某个element的设置是nil=true，那么这个时候在生成的测试脚本的时候胡自动带上nil=true这个信息，而这个时候到了Oracle SOA Gateway进行处理的时候会发生将null值转变为chr(0)隐藏字符进行处理的情况。

FND_API.G_MISS_CHAR中对这个值进行了定义，即如下：

G_MISS_CHAR CONSTANT VARCHAR2(1):= chr(0)，那么按道理在这里将其修改为空串应该可以解决问题。或者找到SOA网关是在哪里解析XML数据的地方进行相应修改。

如果对于XSD文件中，本身nil=false进行设置，则不会带了这个问题。因此是否对WSDL契约结构文件进行修改也可以作为考虑解决问题的方式之一。

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

正文到此结束