转载

技术问题分析06(4.23)

基于前面的技术分析和问题，考虑到如果将所有类型的Server都安装到一个Domain里面，由一个Admin Server进行管理，那么如果Domain或Admin Server出现问题影响就会相对大。因此对整个环境进行重构，对于OSB，JMS，MFT，管控等分别安装到不同的Domain里面并设置不同的Admin Server进行管理。至少在排查问题的时候可以避免各个类型节点之间的相互影响。

对各个Server节点的JVM内存分配也增加到4G，同时对于原来一个Cluster挂接太多的计算节点，本次环境调整还是减少了每个集群中计算节点的挂接。做了上述调整后明显感觉到OSB Server的性能得到了提升。

对于JMS Server进行了单独一个Domain创建，规划JMS集群，同时对Topic主体订阅进行了重建。由于我们在Topic主题的时候启用了用户安全策略user1，实际在我们JMS Server启动后，在JMS Server的服务器日志中不断的报出如下的日志：

BEA-080003 A RuntimeException was generated by the RMI server: 854905596

从网上查询到的资料来看，基本都是说JMS消息分发或接收的时候，由于跨了Domain域需要设置跨越互信的安全策略。具体如下：

启用weblogic的域信任，具体操作如下：

1.登录weblogic控制台，点击左边菜单中的域名称

2.依次点击右边选项卡中的“安全”>“一般信息”

3.点击隐藏的“高级”部分

4.勾选“启用跨域安全”

5.在“身份证明”和“确认身份证明”框中输入相同的认证信息

6.保存和重新启动

更加详细的跨越信任设置可以参考如下链接文章，百度文库可以下载：

https://wenku.baidu.com/view/8f81f94d16fc700aba68fc0e.html?from=search

开始我们理解是OSB Server朝JMS Server发消息出现了该问题，但是没有第一时间想到应该先将OSB Server全部停掉，再来看是否还有该错误。因此我们也在OSB和JMS Server间进行了该设置，但是还是存在在错误日志。后面又考虑到是否是业务系统产生的。

为了验证是否是业务系统产生的该错误日志，我们将所有的非JMS Server节点全部停止，发现仍然有该错误。初步断定是业务系统通过user1用户连接我们的JMS Topic时候报出来的异常错误。因此找业务系统进行相关的跨域互信设置，但是问题已久。最后发现是另外一个业务系统导致的异常，但是为何会导致该问题仍然不清楚。也完全有可能是由于我们的JMS Server环境重新安装，域也进行了调整，而业务系统原来建立的user1的相关JMS连接和会话缓存还在，导致了在监听的时候不断报这个错误。

这个问题最大的感受还是问题定位，知道是跨越互信的问题但是没有快速的定位和缩小范围，导致查找问题花费了不少时间。而该问题首先应该做的就是定位到究竟是哪个业务系统到JMS Server的连接出现了安全验证问题，然后再来排查具体的原因。

这个问题还有一点，就是导致JMS Server报这个异常错误的业务系统本身并不是Weblogic Server，也不存在跨越互信的问题，只是使用了JMS分配的安全用户名进行Topic主题的连接。

对于JMS消息分发的个别性能问题

对于JMS服务器，通过OSB适配后朝JMS Server中发送消息，写入到JMS服务器中的消息再通过业务系统主题Topic订阅被取走。而我们实际在测试过程中发现，对于个别的JMS消息发送耗时很长，比如超过10秒的都有，按道理这种消息分发，如果报文消息量小应该在几十毫秒就完成。

在测试环境没进行重构的时候我们就发现了JMS消息分发慢的问题，但是在环境重构后该问题仍然还存在，即朝JMS消息服务器中写入消息的是花费了很长的时间。而实际上写入JMS消息主要涉及到的步骤是：

1. 初始化上下文：InitialContext

2. 创建JMS连接和会话，Create Conneciton , Create Session

3. 发送消息

而实际上根据我们调试，发现慢的地方主要就是在第1步和第2步，而实际发送消息很快。那获取上下文和创建会话慢的原因，很可能是在当时Pool连接已慢，程序需要等待可用的连接释放才能够进行下一个步骤的操作。

对于Weblogic JMS的一些关键概念如下：

1. 连接工厂(ConnectionFactory): 用来创建消息服务器的connection对象.

2. 连接(Connection): 代表一个与JMS提供者的活动连接.

3. 目的(Destination): 标识消息的发送和接收方式, 分为队列(Queue)和主题(Topic)两种.

4. 会话(Session): 接收和发送消息的会话线程.

5. 为了实现JMS独立于不同供应商MS的专有技术, weblogic JMS采用了受管对象(administratored object)的机制. 受管对象就是由消息服务器通过管理界面创建, 程序通过JNDI接口取得这些对象.weblogic 中的两种受管对象: connection factory, distination.

对于使用Weblogic JMS发送和接收消息，这篇文章写的很详细可以参考：

https://blog.csdn.net/zdp072/article/details/26986675

通俗的说法，获取InitialContext就是寻找jndi树的根结点。然后才能寻找到绑定的jndi元素。在weblogic中获取InitialContext有一定的优化规则。如果访问点和weblogic应用服务器在同一个jvm环境下，建议直接使用 Context ctx = new InitialContext();这样在weblogic回采用优化的方式获取资源，可能不再使用rmi资源，但是依然要求所有对象implementSerializable接口。具体参考

http://www.xuebuyuan.com/2173241.html

对于Weblogic JMS性能调优，参考Oracle官方文档，连接如下：

https://docs.oracle.com/cd/E28280_01/web.1111/e13814/jmstuning.htm#PERFM916

具体设置到的调优内容包括了：

Handling Large Message Backlogs
Cache and Re-use Client Resources
Tuning Distributed Queues
Tuning Topics
Tuning for Large Messages
Defining Quota
Blocking Senders During Quota Conditions
Tuning MessageMaximum
Setting Maximum Message Size for Network Protocols
Compressing Messages
Paging Out Messages To Free Up Memory
Controlling the Flow of Messages on JMS Servers and Destinations
Handling Expired Messages
Tuning Applications Using Unit-of-Order
Using One-Way Message Sends
Tuning the Messaging Performance Preference Option
Client-side Thread Pools

具体是什么原因导致InitialContext慢，暂时还没有找到确切的原因。

又找到一篇文章，具体参考连接，暂时先记录

https://docs.oracle.com/cd/E28280_01/web.1111/e13727/j2ee.htm#JMSPG379

Speeding Up JNDI Lookups by Pooling Session Objects

The JNDI lookups of the Connection Factory and Destination objects can be expensive in terms of performance. This is particularly true if the Destination object points to a Foreign JMS Destination MBean, and therefore, is a lookup on a non-local JNDI provider. Because the Connection Factory and Destination objects are thread-safe, they can be looked up once inside an EJB or servlet at creation time, which saves the time required to perform the lookup each time.

Inside a servlet, these lookups can be performed inside the init() method. The Connection Factory and Destination objects may then be assigned to an instance variable and reused whenever a message is sent.

原文 http://blog.sina.com.cn/s/blog_493a84550102xcu8.html

正文到此结束