Cluster run state changes

To conclude this section, we examine how the WLM plug-in is informed of changes to the cluster configuration:

1. Changes are made to the cluster configuration, such as adding and starting a fourth cluster member to the example.

2. The Deployment Manager pushes the changes to the Node Agents which in turn push those changes to all cluster members.

3. Meanwhile, the EJB client is still performing requests on the cluster.

4. With each request for a remote component, information about the cluster is returned in the response from the cluster member.

If the cluster has been modified since the last request from this client. The WLM plug-in will update its cluster data using the new data returned in the response.

5. The EJB client makes another method call to the remote interface.

6. The ORB that handles the request asks the WLM plug-in for the IOR of the server to contact.

7. The WLM plug-in returns the IOR of the next target, based on the workload management policy, process affinity, and transaction affinity (see 6.5, EJB server selection policy), and the request can be processed by the ORB.

Important: A change in the selection policy does not cause the cluster information to be sent to a client in response to a request. The WLM plug-in will continue using the selection policy defined at the first request. If the cluster topology or the number of cluster members started is changed, the WLM plug-in will get the new selection policy as part of the new cluster configuration in the response.

Each Node Agent monitors the availability of the appservers running on it. Should one of the cluster member servers be stopped then this constitutes a change in run state for the cluster and the Node Agent will notify the Deployment Manager of that change. This information is then pushed out again as was described in step 2.

The Node Agent knows if an appserver is still running by pinging it intermittently. If an application server should fail then the Node Agent will no longer receive responses on its ping messages. In this scenario, the Node Agent will notify the Deployment Manager of the run state change and again this information will be pushed out to the cluster.

If a complete failure of a node occurs, then the Deployment Manager itself will not receive responses from its ping of the Node Agent and the clusters' configuration will be updated.

From this it is possible to see that for the initial request and for workload management to work efficiently, the Deployment Manager and all Node Agents must be up and running. Failure in the Deployment Manager could mean that these run state configuration changes will not get notified to an EJB client in a timely manner.

  Prev | Home | Next

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.