Posted on

Oracle Weblogic Clustering EJBs

Load balancing and failover for EJBs and RMI objects is handled using replica-aware stubs, which can locate instances of the object throughout the cluster. EJBs differ from plain RMI objects in that each EJB can potentially generate two different replica-aware stubs: one for the EJBHome interface and one for the EJBObject interface. This means that EJBs can potentially realize the benefits of load balancing and failover at two levels:

  • When a client looks up an EJB object using the EJBHome stub.
  • When a client makes method calls against the EJB using the EJBObject stub.

The following sections describe clustering support for different types of EJBs.

Clustering Stateless EJBs

Since a stateless bean holds no state on behalf of the client, the stub is free to route any call to any server that hosts the bean. In order to declare a Stateless EJB as clusterable, you need to set to true the element stateless-bean-is-clusterable in your weblogic-ejb-jar.xml:





The stub can automatically fail over in the event of a failure. The stub does not automatically treat the bean as idempotent, so it will not recover automatically from all failures. If the bean has been written with idempotent methods (e.g. there is no additional effect if the EJB is called more than once with the same input parameters), this can be noted in the deployment descriptor as follows, and automatic failover will be enabled in all cases.


    . . . . .



Clustering Stateful EJBs

Method-level failover for a stateful service requires state replication. WebLogic Server satisfies this requirement by replicating the state of the primary bean instance to a secondary server instance, using a replication scheme similar to that used for HTTP session state.

As you can see from the following weblogic-ejb-jar.xmlsnippet, you can configure the replication schema by setting the replication-type element, much the same way we did for the HTTP counterpart:






    <!– None for not to replicate –>




Should the primary server fail, the client’s EJB stub automatically redirects further requests to the secondary WebLogic Server instance. At this point, the secondary server creates a new EJB instance using the replicated state data and processing continues on the secondary server. After a failover, WebLogic Server chooses a new secondary server to replicate EJB session states

Configuring the default load balancing algorithm

WebLogic Server clusters support multiple algorithms for load balancing clustered EJBs and RMI objects: round-robin, weight-based, random, round-robin-affinity, weight-based-affinity, and random-affinity.

By default, a WebLogic Server cluster will use the round-robin method. You can configure a cluster to use one of the other methods using the Administration Console as follows:

  1. Select Environment | Clusters within the Domain Structure panel of the console.
  2. Select a specific cluster. On the General tab, update any of the fields contained as described by the following picture:


You can specify the cluster address using a comma-separated list of hostnames and port numbers.

Remember that any address/port combination in the cluster address must be unique. This means that if you need to run a WebLogic cluster on a single machine, you must ensure all server instances participating in the cluster are assigned a unique port number.

As mentioned in WebLogic documentation, when clients obtain an initial JNDI context by supplying the cluster DNS name (weblogic.jndi.WLInitialContextFactory), it obtains the list of all addresses that are mapped to the DNS name. This list is cached by WebLogic Server instances and new Initial Context requests are fulfilled using addresses in the cached list with a round-robin algorithm. If a server instance in the cached list is unavailable, it is removed from the list. The address list is refreshed from the DNS service only if the server instance is unable to reach any address in its cache.

Using a cached list of addresses avoids certain problems with relying on DNS round-robin alone. For example, DNS round-robin continues using all addresses that have been mapped to the domain name, regardless of whether or not the addresses are reachable. By caching the address list, WebLogic Server can remove addresses that are unreachable so that connection failures aren’t repeated with new Initial Context requests.

Posted on

Configuring Oracle WLS Loadbalancing and High Availability

Load balancing is an essential feature of clustering. WebLogic server has specific load balancing configuration for Web applications. This can be accomplished using a software load balancer or a separate load balancing hardware.

The choice of software load balancer is indeed large and includes Oracle HTTP Server with the mod_wl_ohs module configured, Oracle WebLogic server configured with HttpClusterServlet or the open source Apache Server  mod_weblogic plugin.

For a detailed description of Oracle WebLogic plugins we suggest reading the Oracle documentation available at

Configuring load balancing with Oracle HTTP Server (mod_wl_ohs)

If you want to install mod_wl_ohs then you need downloading Oracle HTTP Server ( .

Oracle HTTP Server is based on the proven, open source technology of Apache Web server and includes all base Apache modules and modules developed specifically by Oracle.

Oracle HTTP Server is based on the proven, open source technology of Apache Web server and includes all base Apache modules and modules developed specifically by Oracle.

Mod_wl_ohs is built-in into Oracle HTTP server; you need however to activate it. Here’s a sample configuration file:

LoadModule weblogic_module “${ORACLE_HOME}/ohs/modules/”


<IfModule mod_weblogic.c>


  WebLogicPort 7001

  WLLogFile /tmp/mod_wl_ohs.log

  MatchExpression *.jsp


  <Location /em>

    SetHandler weblogic-handler


    WebLogicPort 7001




The main sections of mod_wl_ohs.conf are:

LoadModule: loads the weblogic_module when OHS starts.

IfModule: specifies the host and port of the WLS server or cluster and the MatchExpression for proxying by MIME type.

Location specifies application context root for proxying by path.

If both MIME type and proxying by path are configured, proxying by path takes precedence.

Configuring Load balancing with Apache server (mod_weblogic)

If you don’t want to install Oracle HTTP Server to proxy your cluster requests, an open source alternative is Apache Server’s mod_weblogic plugin. This plugin is not part of the WLS distribution so you have to download it from Oracle’s site at

This link will download a bundle of plugins, which are in turn packaged into different operating system distributions, as shown by the following picture:



  1. Unzip the WLSPlugin which matches with your platform and locate the library named from the package. This library needs to be copied into the APACHE_HOME\modules directory of your Apache Web server distribution.
  2. Next step will be editing Apache’s httpd.conf configuration file. Add at first the following line to your APACHE_HOME/conf/httpd.conf file manually:

LoadModule weblogic_module     modules/

  1. Then, include an IfModule block that defines the list of servers/port in the cluster:

<IfModule mod_weblogic.c>


  MatchExpression *.jsp

  MatchExpression *.xyz


If you need to proxy requests by path, use the Location block and the SetHandler statement. SetHandler specifies the handler for the Apache HTTP Server Plug-in module. For example, the following Location block proxies all requests containing /weblogic in the URL:

<Location /weblogic>

  SetHandler weblogic-handler

  PathTrim /weblogic


Choosing between mod_wl_ohs and mod_weblogic

Mod_weblogic and mod_wl_ohs provide almost the same functionalities with few notable differences: mod_wl_ohs  has support for the two-way SSL between OHS and WLS (while Mod_weblogic only supports one-way SSL) and, also, supports IPv6 for communication with WLS.


Posted on

Clustering Oracle Weblogic

A WebLogic Server cluster consists of multiple Managed servers running simultaneously the same applications and working together to provide increased scalability and reliability.

There are a variety of options which you can use to configure a cluster:

  • From within the domain installation wizard, (See Chapter 1, “Creating a WebLogic domain”) you have the option to create a domain made up of a set of Managed nodes which are part of a cluster.
  • If you want to defer the creation of your cluster at a later time, a common option for creating it is by means of the Administration console.
  • If you are an experienced user, then you might try the WLST scripting shell to automate the creation of your cluster. (See Chapter 11, “Creating a cluster with WLST”)

In this chapter we will at first learn how to set up a cluster using the Administration Console and the Managed servers that we have created at the beginning of this book. Then we will learn how to achieve Load Balancing and High Availability for your applications.

Create a cluster from the Admin console

Start up the Administration server and (if you want to control servers from the Web console) the Node Manager. If any of the Managed servers of the domain are running, shut them down, using the Control tab of each server.

  1. From the left tree panel expand the Environment option and select Clusters.
  2. From the Cluster Summary page, click on the New button.
  3. In the Create a New Cluster screen, enter the Cluster Name and select a Messaging Mode as depicted by the following picture:


As you can see, we have chosen “WLSCluster” as Name and left the default options for Messaging Mode (Unicast) and Unicast Broadcast Channel (blank).

Note: the Multicast fields are disabled if you choose Unicast as messaging mode. In the section named “Configuring clustering transport” we detail some more information about Unicast and Multicast modes.

Click Ok. A message will inform you that the cluster was created successfully.

Configuring the cluster address

So far we have defined just a Name and a Messaging Mode for our cluster. You might wonder how your clients (for example a remote EJB client) can access an application running in a cluster of nodes. The answer is the Cluster Address which is used to construct the host name portion of request URLs. You can explicitly define the cluster address when you configure the cluster; otherwise, WebLogic Server dynamically generates the cluster address for each new request.

Dynamic cluster address

If you have not explicitly defined a cluster address, then when a Managed Server receives a remote request, WebLogic Server generates the cluster address, in the form:


Each listen address:listen port combination in the cluster address, corresponds to the single Managed servers and the network channel that received the request.

Explicitly Defining Cluster Address

You can explicitly define a cluster address for a cluster in a production environment by specifying the cluster address as a DNS name that maps to the IP addresses or host names of each WebLogic Server instance in the cluster. In order to do that, select the Configuration | General sub tab of your Cluster definition:

You can specify the cluster address using a comma-separated list of hostnames and port numbers or (highly suggested) as DNS name that is mapped externally to the addresses of all servers that belong to the WebLogic cluster.

Both of these are valid examples of the cluster address for a WebLogic cluster:,,


Remember that any address/port combination in the cluster address must be unique. This means that if you need to run a WebLogic cluster on a single machine, you must ensure all server instances participating in the cluster are assigned a unique port number.