InfoCenter Home >
7: Multimachine management >
7.2 Managing workloads >
7.2.7 Run-time exceptions and failover strategies for workload management

7.2.7 Run-time exceptions and failover strategies for workload management

Workload management run-time exceptions

The workload management service can throw the following exceptions if it encounters problems:

  • org.omg.CORBA.NO_IMPLEMENT. This exception is thrown if the workload management service cannot contact any of the EJB application servers that participate in workload management.
  • org.omg.CORBA.INTERNAL. This exception is thrown when an internal software failure occurs. The error is listed in the WebSphere client trace log. (Be aware that if WebSphere is not installed on the client machine, no logging is performed.)
  • org.omg.CORBA.COMM_FAILURE. This exception is thrown by the ORB when a communications failure occurs. Any current transactions are rolled back, and nontransactional requests are redone.
  • org.omg.CORBA.NO_RESPONSE. This exception is thrown by the ORB when a communications failure occurs.

The WebSphere Application Server client can catch these exceptions and then implement its own strategies to handle the situation; for example, it can display an error message if no servers are available.

Workload management failover strategies

The workload management service uses the following failover strategies, some of which are based on the return values of these exceptions:

  • If the workload management service cannot contact an application server clone, it automatically redirects the request to another clone, providing automatic failover.
  • If the application throws an exception, automatic failover does not occur. The workload management service does not retry the request because it cannot know whether the request was completed.
  • If an org.omg.CORBA.NO_IMPLEMENT exception is thrown, the workload management service has attempted repeatedly to contact the application servers without success. Workload management resumes when application servers become available again.
  • If an org.omg.CORBA.INTERNAL exception is thrown, the workload management service is no longer operating properly and no failover occurs.
  • If the org.omg.CORBA.COMM_FAILURE or org.omg.CORBA.NO_RESPONSE exceptions are thrown, their return value determines whether automatic failover occurs:
    • If one of these exceptions is thrown with a COMPLETION_STATUS of COMPLETED_NO, automatic failover occurs because the request was not completed.
    • If one of these exceptions is thrown with a COMPLETION_STATUS of COMPLETED_YES, failover does not occur because the request was successfully completed.
    • If one of these exceptions is thrown with a COMPLETION_STATUS of MAYBE (which maps to a java.rmi.RemoteException), automatic failover does not occur. The workload management service cannot verify whether the request was completed. In this situation, the client application must anticipate a failure and retry the request. The workload management service then attempts to direct the request to a surviving application server clone.
Go to previous article: Tuning a workload management configuration Go to next article: Workload management for stand-alone Java clients

 

 
Go to previous article: Tuning a workload management configuration Go to next article: Workload management for stand-alone Java clients