技术问题分析10（5.18）
对于JMS分发服务，今天再次报错，前面我们已经分析了实际上导致JMS分发服务长耗时的问题点总结：
1. 仅仅是源服务器和目标JMS不在一台虚拟机上，即Remote发送的时候才会报错。
2. 发送的时候响应长耗时或者是超时，而实际上时间消耗主要在创建JMS连接和会话长耗时。
3. 极大可能是和Weblogic的跨越安全信任有关系，现在还在进步验证和确认过程中。
对于该问题我们前面做了很多的尝试，包括了对OSB Server和JMS Server进行分域拆分，关闭了JMS Server集群，关闭了JMS的动态漂移设置。包括给某个启用了XA事务的业务系统建立独立的JNDI Factory连接工厂。但是该问题仍然没有彻底解决。
当前有一个想尝试的设置现在还没有做，就是在企业跨域安全信任的时候，对于安全互操作模式选择为性能模式，在该模式下远程访问可以启用匿名模式进行访问。在这种模式下很可能常规的跨越安全模式，需要在两边同时配置的身份证明秘钥都不需要。--这个待验证状态。
在前期JMS服务器出现过创建会话超时的错误，顾问指出可能是Oracle Weblogic 12c的线程阻塞模型NIOMuxer可能有问题，在修改为11g使用的PosixMuxer后没有再出现会话超时的情况。因此今天先对JMS服务器进行该设置调整，以再观察下是否还存在长耗时的情况。
对于今天的JMS Server Log日志，关键的记录信息如下：
MessageDrivenEJBBean.onMessage(,Status=Rolled back.
[Reason=Unknown],HeuristicErrorCode=XA_HEURMIX,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=305,seconds
从基本的意思看仍然是XA分布式事务处理超时导致回滚。
整个过程本身通过JMS分为两段，均企业XA事务处理模式，即：
1. 客户端调用JMS分发WS服务，将消息写入到JMS管道
2. 目标系统订阅JMS管道主题，通过OnMessage方法获取订阅信息
JMS分发服务差不多在30分的时候报错长耗时，一直发送3分钟才完成JMS消息的发送，而在33分的时候出现大量订阅端的JMS事务超时回滚的情况。而实际上对于订阅端本身处理入库的逻辑相当快，并不是由于数据处理耗时导致事务回滚。同时和Oracle顾问再次确认本身JMS消息分发和订阅是分离的。
那么关键的问题点还是在30分左右JMS Server本身出现挂起或不稳定的情况，在这个时候不论是JMS消息发送端还是JMS消息订阅端都导致很难快速的获取到JMS Connection并创建会话。所以反应到日志上才是发送长耗时，订阅端事务超时和回滚。
对于为何难以快速的获取到JMS Connection并创建会话，初步认为的原因仍然是跨越安全信任引起的，这个在前面已经说过，对于分发WS服务和JMS在一台虚拟机的时候，没有出现过长耗时的情况。当做Remote的远程分发操作的时候才会出现。
那么现在需要进一步观察的就是什么原因导致JMS Server不可用，仅仅是跨越安全原因，还是说JMS Server本身出现了其它因素影响？对于这块暂时没有进一步的找到答案。
原文 http://blog.sina.com.cn/s/blog_493a84550102xf1u.html正文到此结束
热门推荐
相关文章
Loading...
![[HBLOG]公众号](http://www.liuhaihua.cn/img/qrcode_gzh.jpg)
