Weblogic中的load banlance问题

核心提示： HttpClusterServlet维护一个managed servlet list，每当一个请求被dispatch到某个managed server后，Weblogic中的load banlance问题(2)，server list的index加1，这样在下次dispatch请求的时候，所有客

HttpClusterServlet维护一个managed servlet list，每当一个请求被dispatch到某个managed server后，server list的index加1，这样在下次dispatch请求的时候，请求将会被dispatch到server list中的其他server上去。逻辑很简单，但基本也实现了load banlance功能。

2：InitialContext的load banlance

我们知道，每次我们需要获取jdbc connection， jms connection，ejb stub这类RMI Object的时候，我们都要初始化一个上下文，问题是我们初始化上下文的时候，连接的到底是哪个managed server?

初始化上下文的时候，我们需要提供一个provider url, 如下：

PROVIDER_URL = "t3://localhost:7011";

这种写法很简单，直接连接7001对应的server, 但如果写法如下呢？

CLUSTER_PROVIDER_URL="t3://localhost:7011,localhost:7021";

这时候，load banlance就又来了。10个客户端(weblogic server或者thin client)new 10个InitialContext的话，这10个客户端将55分别连接到后端的两台server上去。实际上客户端在new InitialContext的时候，weblogic会创建一个T3连接到对应的managed server上(RJVMConnection)，注意这个RJVMConnection是个长连接，在同一个JVM中，连向同一managed server的连接只有一个。即如果一个客户端，连续new 10个 InitialContext, 这10个Context实际上是同一对象，weblogic server这时根本不会和后端的server通讯，因为对象已经在client JVM中有了。

new InitialContext的load banlance算法基本和proxy的算法一样，都是维护一个server list, 通过index递增的方法实现。不同的是：在连接某个managed server的connection遇到peer gone的时候， proxy可以recover server list, 而jndi context的load banlance算法则不能。也就是说如果后端有三个managed server， server1， server2相继出现故障的话，所有客户端的context将都会连接到server3, 即使server1, server2能够恢复过来，后续请求也不会连接到他们，除非server3后来出现问题。