7 WebLogic RMI Integration with Load Balancers

This chapter describes WebLogic RMI support for load balancers, including hardware load balancers and web servers with a web server plug-in.

This chapter includes the following sections:

• How WebLogic Server Supports Load Balancers

• HTTP Tunneled T3 Load Balancing

• Native T3 Load Balancing

• Failover Support

How WebLogic Server Supports Load Balancers

WebLogic Server clients that use RMI can interoperate with a load balancer using the following mechanisms:

• When tunneling T3 over HTTP/HTTPS, WebLogic Server supports routing through a hardware load balancer or a web server with a web server plug-in provided that request forwarding mechanism to the WebLogic Cluster is configured to use sticky session routing. See HTTP Tunneled T3 Load Balancing.

• When using T3 directly, WebLogic Server supports using a hardware load balancer to bootstrap the initial T3 connections to the cluster by specifying a PROVIDER_URL that points to the load balancer when creating the JNDI InitialContext. See Native T3 Load Balancing.

Note:

All other uses of a hardware load balancer with WebLogic RMI are unsupported—regardless of whether or not they work.

HTTP Tunneled T3 Load Balancing

When tunneling T3 over HTTP (or HTTPS), the WebLogic Server runtime creates an HttpSession for each RMI session and passes the session ID back and forth between the client and the server using the normal HTTP mechanisms. This allows the web server plug-in or hardware load balancer to route all RMI requests from a particular client back to the same server in the cluster for the duration of that session.

Note:

External load balancers distribute initial context requests that come from Java clients over T3 and the default channel. However, do not route client requests, following the initial context request, through the load balancers. When using the T3 protocol with external load balancer, you must ensure that only the initial context request is routed through the load balancer and that subsequent requests are routed and controlled using WebLogic Server load balancing.

How to Configure the External Listen Address

WebLogic Server provides an External Listen Address to provide an IP address to use in RMI stubs to allow clients to connect to the server through a Network Address Translating (NAT) Firewall. As long as the NAT firewall maps a unique external IP address to the unique internal IP address of the server, each stub delivered to the client uniquely identifies the cluster member holding the object that the stub is a proxy for. The External Listen Address is set differently for default and custom network channels:

• For the default channel, use the ExternalDNSName attribute on the ServerMBean. See ExternalDNSName in MBean Reference for Oracle WebLogic Server.

• For a custom channel, use the PublicAddress and PublicPort on the NetworkAccessMBean. See NetworkAccessPointMBean in MBean Reference for Oracle WebLogic Server.

Example Custom Channel Configuration for a Load Balancer

Configure a T3 network channel on all WebLogic Server instances in the cluster. The network channel accepts tunneled traffic from the load balancer. To ensure all client requests are routed through the load balancer, set External Listen Address to the end point where loadbalancer, or the web server, accepts traffic from the client. Enable HTTP protocol and set tunneling-enabled=true. Configure the load balancer or web server to route http traffic to WebLogic Server. If using Oracle HTTP Server (OHS) as a webserver, this can be achieved by changing the httpd.conf configuration file. For example:

The WebLogic Server config.xml:

<network-access-point>
      <name>tunnelChannel</name>
      <protocol>t3</protocol>
      <listen-address>example.com</listen-address>
      <listen-port>11001</listen-port>
      <http-enabled-for-this-protocol>true</http-enabled-for-this-protocol>
      <tunneling-enabled>true</tunneling-enabled>
      <outbound-enabled>false</outbound-enabled>
      <enabled>true</enabled>
      <two-way-ssl-enabled>false</two-way-ssl-enabled>
      <client-certificate-enforced>false</client-certificate-enforced>
</network-access-point><network-access-point>
. . .

OHS/Webtier's httpd.conf file

<LocationMatch ^/bea_wls_internal/>
SetHandler weblogic-handler
WeblogicCluster example.com:11001
</LocationMatch>
. . .

Session Failover

Session failover is transparent to the client. When a server shuts down the client RJVM receives a PeerGone exception. This causes the HTTPClientJVMConnection to be closed. When the next request comes from the same client, the request is failed over to the next member in the cluster for both stateless and stateful beans. If an exception occurs during request processing, that request is not failed over and the exception is propagated to the client.

Cookie Persistence

The tunneling client caches the cookie it receives after initial request and sends it back in every subsequent request.

Pinned Objects

In a cluster, even if an object is pinned and the replicate_bindings!= false, the stub is replicated to all the members of the cluster. Tunneling does not affect the normal pinned object behavior.

Stateful Session EJBs

If External Listen Address is not set, the stub that the client gets back has the list of available hosts to route to and the behavior is similar to sending direct t3 requests.

If External Listen Address is set then failover does not work because the primary and secondary hosts get set to the externalDNSName and load balancer hangs trying to route to itself.

Native T3 Load Balancing

If the cluster member fails, the client invocation on a non-cluster-aware stub also fails since the firewall does not attempt to redirect the request to another cluster member. For a cluster-aware stub invocation, the request should be transparently routed around the failure and the invocation delivered to a different cluster member using the External Listen Address contained in the cluster-aware stub. See How to Configure the External Listen Address.

Use the hardware load balancer to load balance the initial T3 connection request when creating the JNDI InitialContext by specifying a PROVIDER_URL that points to the load balancer provided that the External Listen Address is not set to point to the hardware load balancer. This configuration works because the hardware load balancer is only involved in routing the initial TCP connection request to one of the managed servers. Once the connection is established, all RMI stubs contain the server's ListenAddress (or External Listen Address in the case of a NAT firewall) that uniquely identifies the server for which the stub is acting as a proxy.

Failover Support

WebLogic RMI does not support failover when used with a hardware loadbalancer.

For information on how WebLogic Server RMI handles failover, see Failover and Load Balancing RMI Objects.