+

Search Tips   |   Advanced Search

Workload is not getting distributed

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

    1. 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 in both...

      • app_server_root/logs
      • app_server_root/logs

    2. Analyze the service log (activity.log) of the deployment manager and any nodes encountering problems. View the activity.log files in...

        profile_root/logs

    3. If Java exceptions appear in the log files, examine the trace stack and looking for a product-related class near the top of the stack (names beginning with com.ibm.websphere or com.ibm.ws) that created the exception.

      For example, if the exception appears to have been thrown by a class in the com.ibm.websphere.naming package, review the Naming Services Component troubleshooting tips topic.

  2. Browse the JVM logs of the problem deployment manager and application servers:

    1. If Java exceptions appear in the log files, examine the trace stack and looking for a product-related class near the top of the stack (names beginning with com.ibm.websphere or com.ibm.ws) that created the exception.

      For example, if the exception appears to have been thrown by a class in the com.ibm.websphere.naming package, review the Naming Services Component troubleshooting tips topic.

  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. Although the problem is happening in a clustered environment, the actual cause might be only indirectly related, or unrelated, to clustering. Investigate all relevant possibilities:

    1. If an enterprise bean on one or more servers is not serving requests, review the Cannot access an enterprise bean from a servlet, JSP, stand-alone program, or other client and Cannot look up an object hosted by the product from a servlet, JSP file, or other client topics.

    2. If problems seem to appear after enabling security, review the Errors or access problems after enabling security topic.

    3. If an application server stops responding to requests, or spontaneously dies (its process closes), review the Web module or application server dies or hangs topic.

    4. If SOAP requests are not being served by some or all servers, review the Errors returned to client trying to send a SOAP request topic.

    5. (iSeries) If we have problems installing or deploying an application on servers on one or more nodes, review the Troubleshooting code deployment and installation problems topic.

  5. (iSeries) If our 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-based 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-based systems, to avoid inserting these characters.

  6. (iSeries) Check for troubleshooting tips for the workload management component.

  7. Check to see if the problem is identified and documented by looking at available online support (hints and tips, technotes, and fixes).


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 the product 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 that have been set for each of those members. This is done by following the steps in the topic Troubleshooting the Workload Management component.

(ZOS) Workload management in the product is based on a round robin scheme of request distribution. 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 that have been set for each of those members.

(ZOS)


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

Some possible causes of this problem are:


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

This error occurs when previously unavailable servers are not recognized by the workload management component after those servers 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.

We 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

We 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 
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 the 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 our primary and backup clusters match.

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


  • Troubleshoot administration
  • View JVM logs
  • Add logging and tracing to the application
  • Multiserver environment errors
  • Workload management component troubleshooting tips
  • Application client SOAP request troubleshooting tips
  • Web server plug-in 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
  • Web module or application server stops processing requests
  • Application deployment problems
  • Web resource is not displayed
  • Access problems after enabling security
  • High Performance Extensible Logging