This chapter includes the following sections:
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.
All other uses of a hardware load balancer with WebLogic RMI are unsupported—regardless of whether or not they work.
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.
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 Oracle WebLogic Server Administration Console Help.
For a custom channel, use the
PublicPort on the NetworkAccessMBean. See "NetworkAccessPointMBean" in Oracle WebLogic Server Administration Console Help.
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
<network-access-point> <name>tunnelChannel</name> <protocol>t3</protocol> <listen-address>foo.bar.Company.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> . . .
<LocationMatch ^/bea_wls_internal/> SetHandler weblogic-handler WeblogicCluster foo.oracle.com:11001 </LocationMatch> . . .
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 propogated to the client.
The tunneling client caches the cookie it receives after initial request and sends it back in every subsequent request.
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.
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.
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.
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
External Listen Address in the case of a NAT firewall) that uniquely identifies the server for which the stub is acting as a proxy.
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.