转载

技术问题分析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

正文到此结束

所属分类： Java 编程技术

本文标签： 模型 web 配置 Connection 分布式远程访问安全企业 IO rmi 集群总结 NIO 线程分布式事务 bean Oracle HTML CTO message remote 时间 JMS 服务器数据 http
版权声明： 本文为互联网转载文章，出处已在文章中说明(部分除外)。如果侵权，请联系本站长删除，谢谢。
本文海报： 生成海报一生成海报二

本站定位：个人技术类博客

本站作用：写博客、记日志、闲聊扯淡鼓捣技术。