7.5.1 Server weighted round robin

The server weighted round robin routing selects the next currently available cluster member based on a specific round robin algorithm. The policy ensures a distribution based on the set of server weights assigned to the members of a cluster. For example, if all servers in the cluster have the same weight, the expected distribution for the cluster would be that all servers receive an equal number of requests. Otherwise, the distribution mechanism sends more requests to the higher weight value servers than the lower weight value servers. The policy ensures the desired distribution, based on the weights assigned to the cluster members. Weighted round robin policy greatly benefits an environment that has unbalanced hardware.

The server weight value defaults to 2 for each member of the cluster and is maintained in the cluster routing table.

When setting the server weight values for the cluster members, you should utilize low values to avoid load variations.

For example, you would be better off setting server weights to 2 and 5 versus 8 and 20 so that the refresh will occur more often and thus the server with the weight of 8 will not have to sit idle while 12 requests go to the server with a weight of 20. This way, it only sits idle for three requests instead of 12 requests.

If a particular EJB server instance is stopped or otherwise unavailable, that instance is skipped (no attempt is made to select it) until it can be verified as being back in service.

The ORB WLM plug-in in the EJB client maintains a routing table for each server cluster. The routing table is re-calculated for every new request coming in. There are no additional requests to an appserver once its outstanding request ratio has reached its server weight value, but there are exceptions to this rule: Transaction affinity

Within a transaction, the first time an EJB server is chosen, the prevailing selection policy for the cluster member is applied. After the EJB server is selected, it remains bound for the duration of the transaction. Process affinity

This means that the EJB client and server are configured in the same appserver. For example, the EJB container and Web container share the same appserver and a servlet invokes an EJB, then the Web container never routes EJB requests to a container in another appserver.

Process affinity applies to servlet and EJB clients only. It does not affect stand-alone Java clients, because their EJB requests come from outside of the appserver process. More on Transaction and Process affinity can be found in 7.5.3, Process affinity and 7.5.4, Transaction affinity.

Let us take a close look at how server weighted round robin works in WAS V6. A server cluster has two cluster members as illustrated in Figure 7-6.

Cluster member Server1 has a weight value of 4, another member, Server2, is weighted 1. After the bootstrapping process, the EJB client of this cluster gets the server clustering information, in particular the routing weight for each cluster member. Then, the ORB WLM plug-in creates and caches a WLM routing table reflecting the weight value of all available cluster members. In our example, this means 4 and 1 for Server1 and Server2 respectively. The selection decision of which cluster member to send the request to is based on the value provided by this table.

Table 7-3 describes how the routing table dynamically controls the client request workload management:


After request	Server1 weight	Server2 weight
0 requests (initial state)	4	1
1. request	3	1
2. request	3	0
3. request	2	0
4. request	1	0
5. request	0	0
Reset:	4	1

Server weighted round robin routing table

1.	Before the EJB client makes its first request, the routing table reflects the server weights: 4 and 1.

2.	The first EJB request is routed to Server1 because of its higher weighted value. After this request, the weight for Server1 is decreased by 1 to 3 in the routing table; Server2 still has a weight of 1.

3.	The second request goes round robin to Server2 and finds that its weight is greater than 0. Server2 is picked for this request, consequently, its weight is decreased to 0 after the second request.

4.	After the third request, which was sent to Server1, the routing weights become 2 and 0.

5.	Now, since Server2 has a weight of 0, all further requests are routed to Server1 until Server1's weight value also reaches 0 (for exceptions to this rule, please see the Note below).

6.	Finally, the routing table has values of 0 and 0 for both servers. Now, the reset occurs and the initial weights are added back. Subsequent requests follow the same pattern to provide the EJB client a flexible workload management.

Notes:

-	The routing table is decremented on each new request. No new requests are sent to an appserver once its routing entry reaches zero or less, except when overridden by:

Affinity (Transaction, HTTPSession)

In Process (handled by ORB)

Prefer Local

The original weights are added back even if a server has a weight below zero (for example because of transaction or process affinity). This might result in negative or zero weights for a server even after the reset. Please note that this behavior is different from that of the plug-in WLM (as described in 6.6.1, Processing requests) where the reset always results in positive weights because the plug-in adds multiples of the original weights if needed.

WAS V6 introduces a new feature called "fairness balancing" for EJB WLM. For example, weights of 2 and 7 will result in a "a-bbbb-a-bbb" distribution rather than "a-b-a-bbbbbb". This further reduces the possibility of load variations. However, using low weight values (for example 4 and 1 instead of 12 and 3) is still recommended.