首先记录下最近做的修改的情况
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://www.tuicool.com/articles/BFfABfZ