Workload is not getting distributed

 

+

Search Tips   |   Advanced Search

 

  1. General Troubleshooting
  2. HTTP requests are not distributed to all servers
  3. Enterprise bean requests are not distributed to all servers
  4. Enterprise bean requests are not distributed evenly
  5. A failing server still receives enterprise bean requests (failover is not completed)
  6. Stopped or hung servers do not share the workload after being restored
  7. A cluster does not fail over to its backup cluster

 

General Troubleshooting

  1. Browse the JVM logs of the problem deployment manager and appservers:

  2. Use the Log and Trace Analyzer tool to browse and analyze the service log (activity.log) of the deployment manager and any nodes encountering problems. View the activity.log files...

    If Java exceptions appear in the log files, try to determine the actual subcomponent that is directly involved in the problem by examining the trace stack and looking for a WAS-related class near the top of the stack...


    com.ibm.websphere.*
    com.ibm.ws

  3. Ensure that all the machines in the configuration have TCP/IP connectivity to each other by running the ping command:

    1. From each physical server to the deployment manager
    2. From the deployment manager to each physical server

  4. If your topology consists of a Windows-based deployment manager with supported UNIX systems servers, browse any recently-updated .xml and .policy files on the supported UNIX systems using vi to ensure that Control-M characters are not present in the files. To avoid this problem in the future, edit these files using vi on the supported UNIX systems, to avoid inserting these characters.

 

HTTP requests are not distributed to all servers

If HTTP requests are not being distributed to all servers:

 

Enterprise bean requests are not distributed to all servers

If a client cannot reach a server in a cluster thought to be reachable, a server might be marked unusable, or is down. To verify this:

 

Enterprise bean requests are not distributed evenly

There are a number of possible reasons for this behavior, which generally fall into one or more of these categories:

Workload management in WAS is based on a weighted proportional scheme to spray requests among the servers. This results in balance being determined by numbers of requests rather than by any other measure. A true balance problem is determined by comparing the number of requests processed by each member of the cluster with the weights set for each of those members. This is done by following the steps in the topic "Troubleshooting the Workload Management component".

 

A failing server still receives enterprise bean requests (failover is not completed)

Some possible causes of this problem are:

 

Stopped or hung servers do not share the workload after being restored

This error occurs when the servers that were unavailable are not recognized by the Workload Management component after they are restored. There is an unusable interval determined by the property com.ibm.websphere.wlm.unusable.interval during which the workload manager waits to send to a server that has been marked unusable. By default this is 5 minutes.

You can confirm that this is the problem by ensuring that servers that were down are now up and capable of servicing requests. Then wait for the unusable interval to elapse before checking to determine whether failover occurs.

 

A cluster does not fail over to its backup cluster

You might experience an error that is similar to the following sample:

[10/11/04 13:11:10:233 CDT] 00000036 SelectionMana A WWLM0061W: An error was encountered sending a request to cluster member {MEMBERNAME=FlorenceEJBServer1, NODENAME=fwwsaix1Node01} and that member has been marked unusable for future requests to the cluster "", because of exception: org.omg.CORBA.COMM_FAILURE: CONNECT_FAILURE_ON_SSL_CLIENT_SOCKET - JSSL0130E: java.io.IOException: Signals that an I/O exception of some sort has occurred. Reason: Connection refused vmcid: 0x49421000 minor code: 70 completed: No"

Perform the following steps to fix the configuration:

  1. Review your deployment manager hostname and bootstrap port for each backup cluster setting.

  2. Review your core group bridge peer ports to make sure the hostname and distribution and consistency services (DCS) port are accurate.

  3. Verify that the names of your primary and backup clusters match.

  4. If your application is going through security to go to the backup cluster, review your security configuration. You might need to use single sign on (SSO) and import the LTPA keys to the backup cell.

If you do not find your problem listed there, contact IBM Support.

For current information available from IBM Support on known problems and their resolution, see the IBM Support page. You should also refer to this page before opening a PMR because it contains documents that can save you time gathering information needed to resolve a problem.


 

Related tasks

Troubleshooting administration
View JVM logs
Adding logging and tracing to your application

 

Related Reference

Multiserver environment errors
Workload management component troubleshooting tips
Naming service troubleshooting tips
Application access problems
Enterprise bean cannot be accessed from a servlet, a JSP file, a stand-alone program, or another client
Application client sending SOAP request receives errors
Web module or appserver stops processing requests
Application deployment problems
Web server plug-in troubleshooting tips
Web resource is not displayed
Access problems after enabling security