当前位置: 代码迷 >> Web前端 >> WebLogic Server高级管理之六:集群上的JMS配置
  详细解决方案

WebLogic Server高级管理之六:集群上的JMS配置

热度:401   发布时间:2012-11-19 10:18:51.0
WebLogic Server高级管理之六:集群下的JMS配置

首先声明,该博文转自热爱生活,热爱JAVA,原文地址为http://maping930883.blogspot.com

在WebLogic Server中,JMS Server是依附于Managed Server而运行的,不能独立运行,因此也就不存在把JMS Server 部署到集群上的这种设置。
每一个JMS Server上有各种JMS 资源如Queue和Topic;且每一种JMS资源都是pinned to JMS Server的。所以,普通的JMS资源无法实现集群下的负载均衡和容错功能。
JMS集群是通过配置Distributed JMS资源来实现的,比如distributed Queue。
一个Distributed Queue是一个虚拟的JMS资源,即并没有一个物理的JMS Queue对应它。
它是通过在每一个JMS Server上创建一个物理的JMS Queue来实现负载均衡的。
注意,这些JMS Server对应的Managed Server是属于一个集群的。
用户并不知道消息是发送到了哪些物理Queue中(他不需要知道),他只知道是发送到了Distributed Queue中。
设计图如下:



具体设置步骤如下:

1. 把message应用部署到集群上。

2. 创建JMS Server: dizzyworldJMSServer2,部署到dizzy2上。

3. 创建JMS Module: dizzyworldClusterJMSModule,部署到集群上。

4. 在dizzyworldClusterJMSModule中创建Subdeployments:dizzyworldClusterSubdeployment,部署到集群上。

5. 在dizzyworldClusterJMSModule中创建Distributed Queue:dizzyworldDistributedQueue,部署到dizzyworldClusterSubdeployment上。
点击dizzyworldDistributedQueue,查看其Member成员,会发现在JMS Server和Server2中各自创建了一个Queue。
这些Queue才是真正的物理Queue。





6. 在dizzyworldClusterJMSModule中创建Connection Factory:dizzyworldConnectionFactory,部署到dizzyworldClusterSubdeployment上。
点击dizzyworldConnectionFactory,选择Configuration-->Load Balance中,在不要选中“Server Affinity Enabled”。
这样做是为了“去亲属化”,否则每个JMS Server会优先考虑把消息放到自己的Queue中。


7. 运行http://localhost/message。
向dizzyworldDistributedQueue中发送三条不一样的信息。

8. 在Console中,点击dizzyworldDistributedQueue,选择Monitor:
会看到两个JMS Server上的Queue中收到了消息。



注意,处理请求的Managed Server,与消息是否发送到该Server所对应的JMS Server没有必然关系。
比如,我的实验结果是:dizzy2处理了2个请求,dizzy1处理了1个请求,但是JMS Server2中的Queue只有1条消息,而JMS Server中的Queue有2条消息。
这应该是“Server Affinity Enabled”选项的作用。
  相关解决方案