InfoCenter Home >
8: Problem determination >
8.4: Traces >
8.4.1: Trace samples >
8.4.1.3: Workload Management/Cloning/Remote Administration Problems

8.4.1.3: Workload Management/Cloning/Remote Administration Problems

Unlike WebSphere Application Server Advanced Edition, the Standard Edition does not support the Workload Management function. WebSphere Application Server Standard Edition is limited to a single physical server. However, Standard Edition provides multiple JVMs that can be mapped to multiple virtual hosts on a single HTTP Server. Therefore multiple Web sites can still be hosted using one Standard Edition Application Server.

Description of the Workload Management function and cloning

Like the Standard Edition, WebSphere Application Server Advanced Edition provides multiple JVMs, but it also supports distributed system management for networks and clusters of Advanced Edition Application Servers. Distributed system management is an outcome of the the Workload Management function. This function enables cloning, or creating instances of a model. Clones can be created on a single machine or across multiple machines in a cluster. Modifying a model automatically propagates the changes to all of its clones. By administering a model, you can simultaneously administer several copies of a server (the clones).

Scalability in a workload management environment occurs in two forms:

  • Horizontal scaling - the number of concurrent connected users.
  • Vertical scaling - the number of concurrent requests.

With Workload Management, requests can be routed to any server on any node with the same results. Workload Management provides for Failover where requests are routed to other nodes (servers) when one node fails. Failover occurs without affecting throughput or reliability.

Workload Management and Cloning problem descriptions

The following resources can be cloned. Select a specific type of resource to view typical problem scenarios.

Application Server issues

There may be some performance impacts using cloning:

  1. Make small, incremental changes to your model to minimize performance hits on the client.
  2. Change your model when few clients and servers are running.
  3. You do not need to reconfigure server groups to reflect an unavailable server unless that server will be unavailable for an extended period of time. In that case, reconfigure the model to optimize performance.
EJB Containers and Enterprise Beans

Homes of session beans have special information to indicate that these "homes" are workload management (WLM) enabled; that is, deployed on one or more servers. When a client accesses the home of a session bean, the client is referred to the homeOfHomes on the Admin Server. The client then creates proxies for each clone using a specific workload management policy as for example, round robin.

Problems occur when:

  • Client stubs are generated that are not WLM enabled. All stubs generated by VisualAge for Java are WLM enabled. For those stubs not created through VisualAge for Java, you must use the wlmjar file.
  • Client stubs are WLM enabled but should not be. To create non-WLM stubs, use "rmic -iiop" and jar the output files.
  • You WLM enable a stateful session bean instead of its container.
  • If all your requests are sent to the same server, verify that your client jar file is WLM enabled. Use jar -tvf on the jar file, and verify the jar file contains both x_Stub and x_BaseStub, not just x_Stub.
Servlet Engines, Web applications and Servlets

If requests are going to one server, verify that your model has more than one clone. Also verify that each clone has xBean deployed. This particularly applies to a Thin Servlet Redirector configuration since the ThinRedirector is an EJB client to the RemoteSRP bean. Also verify that the first server in the model is running. The first server must be running for the lookup phase to work correctly.

Remote Administration

You can remotely administer WebSphere Application Server using:

Remote admin console

Use can run admin console remotely using the adminclient.bat file on Windows NT, or adminclient.sh file on UNIX. See article Administrative models for more information on implementing a remote admin client.

Typical remote admin console problems are:

  • com.ibm.ejs.util.cache.FaultException error occurs in the stack trace because the JDK running on the client machine cannot communicate with the JDK running on the Admin Server machine. The resolution is to upgrade the backlevel JDK.
  • The NAT (Network Address Translation) function in firewalls cannot be used with a remote admin client. The internal address of the Admin Server is not recognized by the admin client outside the firewall. No circumvention exists for this problem.

X Windows clients on UNIX machines

X windows client software can run on any platform but requires a UNIX X Windows Server. (Currently the X Windows Server is only available on AIX and Solaris platforms.)

Typical X window client problems are:

  • You cannot run an admin console remotely through the X windows client using an authorized, non-root account with global security enabled. Error message, FATAL Could not bind to the Admin Server on {0}{1}, appears on the screen when the adminclient .sh or .bat file is executed. No circumvention exists for this problem.

Web based WebSphere admin console

See article Web administrative console overview for information on configuring and implementing a Web based admin console.

Go to previous article: Servlet Redirector Problems Go to next article: Identifying the Problem

 

 
Go to previous article: Servlet Redirector Problems Go to next article: Identifying the Problem