技术问题分析15(6.28)

对于JMS消息发布订阅的技术问题，这周基本正式解决，因此该篇也是最后一篇总结文章。

对于JMS业务系统订阅事务处理超时问题

从前面的技术问题分析，我们可以看到有两个关键内容，第一个就是调用WS服务发送消息到JMS主题出现延迟比较长的问题，这个通过调整Weblogic启动参数设置以及解决；第二个问题就是业务系统进行Topic订阅的时候，由于启用了XA分布式事务，在日志里面经常大量出现超时事务回滚的问题，这个问题本周已经基本解决，最终是由于JMS Server到订阅Server间的网络策略没有开通引起。

该问题我们排查了很久，前面都将重点放在了跨越安全认证，超时时间设置等方面，但是问题一直没有得到有效解决。本周请了Oracle专家顾问到现场诊断后，最终才解决了问题。

我们再来看下实际从订阅日志里面发现的关键异常信息如下：

Name=NewJMSMessagePoller.MessageDrivenEJBBean,

Xid=BEA1-5C2275BFC49885DEDA81(92917295),Status=Rolled back. 

[Reason=Unknown]

[ServerCoordinatorDescriptor=(CoordinatorURL=AdminServer+10.24.15.111:7031+

EBS_domain_ERPSIT+t3+, XAResources={WSATGatewayRM_AdminServer_EBS_domain_ERPSIT},

NonXAResources={})],CoordinatorURL=jms_server9+10.24.19.9:9300+sit_domain+t3+):

在这里可以看到明确的Error错误，原因是XA事务超时回滚。下面是详细的信息，但是从这个日志我们也很难就分析出来是JMS Server 10.24.19.9到 10.24.15.111:7031这个业务系统的IP+端口不通导致。

在JMS Console管控台，通过观察和监测JMS线程，对线程进行转储处理后，观察日志，在日志里面我们可以发现上述类似的信息。但是同时会发现一个关键信息如下：

java.lang.Thread.State: RUNNABLE

 at ***   Socket Connect

从这里可以较为明显的看到是建立Socket Connect的时候出现连接等待，线程处于locked状态。而再看下面的堆栈可以看到关键的信息是connectToAddress的时候出现问题，即建立某个目标地址的连接的时候出现问题，那么究竟是建立什么连接出现问题。

这个时候可以用netstat命令，在JMS Server上列出当前处于同步等待的请求。当我们用这个命令行工具分析和排查的时候，就发现是JMS Server到业务系统的IP+端口地址不通导致了。因此在走网络策略申请，开通了这个网络策略后，困扰多时的订阅端业务系统事务处理超时和回滚问题得到彻底解决。

我们来看下整个过程

A Server：JMS Server，提供Topic主题订阅信息。

B Server：业务系统服务器，对A Server消息进行订阅，方式为通过Weblogic MDB来实现。

对B订阅程序，在接收到Topic的消息后，需要将数据写入到数据库，完成整个过程。即两个阶段可以如下来进行理解，如下：

第一阶段：A Server将消息送达到B Server，同时准备从队列中移除；同时B Server获取到消息，将消息写入到数据库中。两边各自完成各自操作。

第二阶段：XA事务协调器发起Commit请求，A Server正式将消息从队列和持久化存储中移除，同时B Server将数据库事务完成并提交。

这个时候XA事务协调器是在A Server上面，即在第一阶段成果完成后，A Server上的事务协调器需要朝B Server发送通知信息，通知B Server可以进行二阶段提交了。而由于网络策略不通，导致B Server一直无法接收到这个信息，因此导致事务超时出现回滚。同时由于我们在JMS的超时设置中，原来二阶段超时设置都设置的1天时间，所有可以看到大量的不断重试连接不成功，超过了1天才超时的情况，也同时看到了在JTA线程中有大量线程出现Rollback事务回滚。

对于JMS消息订阅延迟的问题

对于JMS消息订阅延迟的问题，经过分析在JMS管理台看到订阅系统处于离线状态。这个离线可能是由于网络中断，两边的业务系统重启等多种原因造成了订阅方系统出现掉线。因此解决的方法就是需要有一种重试和重连机制来保证目标系统处于在线状态。

具体实现很简单，即在Spring配置文件中增加如下信息：

Spring配置实现样例说明：