转载

技术问题分析11(5.24)

在这里先把最近技术问题分析和诊断的一些进展做下记录。

首先对于测试环境，我们在上周调整了一个参数，即weblogic 12c自带的NIOMuxer实现有性能问题，比如可能会出现线程死锁，线程处理慢，按照后台给的建议修改为11g中老的PosixMuxer实现。在这参数修改后，在SIT环境进行的JMS分发服务测试，没有在出现分发服务本身长耗时和超时的情况。

但是继续监控JMS Log日志，发现仍然有业务系统连接过来的订阅会话，出现事务超时和事务回滚。在前面我们已经说了一直怀疑的一个关键原因是跨越安全信任的问题，在前面也专门写了一篇文章讲跨越安全信任如何进行设置和分析。在该问题提交到Oracle SR后，Oracle的技术顾问希望我们增加Weblogic启动时候的Debug参数设置，在增加了这些参数设置后，可以进一步更加详细的记录到JTA和分布式事务，两阶段提交的详细错误日志信息。基于昨天的Log日志记录，可以抓取到的有用信息为：

BEA-000000

Cannot obtain Coordinator: AdminServer+10.24.15.111:7031+EBS_domain_ERPSIT+t3+

基于这个错误信息，我们进一步搜索Oracle的Support知识库，能够发现一篇文章如下：

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=426905789235072&id=2356893.1&_afrWindowMode=0&_adf.ctrl-state=jvksy1gxv_58

除了上面的异常信息外，这篇文章里面还Log了如下信息：

java.lang.SecurityException: User does not have access to the administrator port.

at weblogic.utils.StackTraceDisabled.unknownMethod()

从这个错误来看是由于匿名访问Admin端口导致的错误，而在跨越信任里面谈到过，如果对于安全互操作模式如果修改为性能的话，是可以支持匿名访问的。根据这篇文章的的内容要说明的就是，即使你在控制台设置了安全互操作模式是性能，但是仍然会出现安全原因导致无法访问，并进一步引发无法获取事务协调器和超时。

该篇文章的错误描述和我们Log日志里面的记录相对类似，并说明是Weblogic本身的一个Bug，但是这个Bug和补丁程序只对应Weblogic 12.1.3版本。而我们当前使用的Weblogic是 12.2.1.3版本。没有对应的补丁可以修复。同时假设是业务系统本身的Weblogic版本有问题，经过询问业务系统使用的是10版本，也没有对应的补丁程序可以打。该问题只有暂时搁置。

但是对于业务系统订阅JMS消息采用较低的Weblogic Server版本，是否存在两个版本差异较大而带来的版本兼容性等问题，暂时也无法得知。

对于在开发环境，在跨越安全设置中的三种设置中，我们启用了安全互操作模型，同时将下拉框的内容修改为了性能，两边业务系统的服务器都进行了修改并进行了重启。再进行JMS Server的Log日志监测的时候没有再发现类似Security安全错误的异常日志。

但是在对开发环境测试服务器的Log进行监控了的时候，仍然会发现了事务回滚超时，BEA-110423等相关的错误信息。而且在开发环境仍然不是的出现，主要还是是对于匿名访问的JMS订阅消息会出现这个错误。

BEA-110423 Abandoning transaction after 86,454 seconds

Name=JMSMessagePoller.MessageDrivenEJBBean

Xid=BEA1-0B01A6978B5308188CB2(876162763),Status=Rolling Back.

Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 3003 seconds

对于JTA事务处理超时，实际在Weblogic Domain JTA选项卡下面有两个超时时间可以进行设置。

1. 超时秒数：指定在两阶段提交事务处理中允许活动事务处理处于第一阶段的最长时间 (秒)。如果指定的时间到期, 则将自动回退该事务处理。

2. 放弃超时秒数：指定事务处理管理器坚持尝试完成两阶段提交事务处理的第二阶段的最长时间 (秒)。

而对于 86,454 这个日志里面的时间正好是对应到我们放弃超时秒数，简单来说就是在XA分布式事务和两阶段提交中，是第二阶段的提交处理导致了事务处理超时。但是对于JMS消息主题这种XA分布式事务，第二阶段究竟是JMS持久化入库或清除消息，还是所目标端接收消息入库，暂时还没具体分析。

对于原来JTA事务处理超时时间设置为30秒，后面一方业务系统将其修改为3000秒，但是可以看到即使设置的是3000秒仍然会出现事务超时和回滚的情况。而是JMS消息订阅错误根本就不需要这么长的时间进行处理。对于该问题暂时没有找到解决问题的方法。