Weblogic中的load banlance问题

核心提示： 值得一提的是：context所有的相关操作时server affinity的，而非load banlance，Weblogic中的load banlance问题(3)，比如：2个客户端分别new了个context, 分别连接到server1和server2上，连接到server1的context

值得一提的是：context所有的相关操作时server affinity的，而非load banlance。比如：2个客户端分别new了个context, 分别连接到server1和server2上，连接到server1的context，做了10次lookup，那么这10次操作，都在server1上完成，不会在server2上作任何操作。所以说jndi级别的load banlance不是绝对均衡的。

3: JMS Distributed Queue的load banlance

Distributed Queue(简称DQ)，顾名思义，分布式队列。在不同的JMS Server上，我们会创建不同的物理Queue, 按照传统方式，我们在发送消息(或者创建JMSSession)的时候，需要指定一个物理Queue，这样我们可以将消息发送到固定的Queue上。 由于在Weblogic server上， JMS Server是一个pin service，即只能运行于单个managed server上的服务实例。 如果我们发送消息的时候，指定Queue对应的jms server出现了问题，这样消息无法发送出去。基于这个原因， Weblogic上提出了DQ，DQ是个逻辑Queue,并没有时间的物理Queue与其对应，它用于管理多个、分布于不同jms server上的物理Queue, 这样客户发送、接受消息的时候，需要指定的是DQ，而不是物理Queue。客户端知道的只是将消息发送到了DQ，而无法知道到底发送到哪个具体的物理 Queue上了。那么Weblogic是如何计算消息该发送到具体物理Queue呢？

JMS Connection Factroy的配置选项中load banlance参数：LoadBanlanceEnabled，ServerAffinityEnabled

Distributed Queue的配置选项中load banlance参数：LoadBanlancePolicy，默认为Round-Robin， 可选值包括：Round-Robin, Random

Load Balancing Enabled:

Specifies whether non-anonymous producers created through a connection factory are load balanced within a distributed destination on a per-call basis.