Web container failures and failover

When a Web container fails, it is the responsibility of the HTTP server plug-in to detect this failure and mark the Web container unavailable. Web container failures are detected based on the TCP response values, or lack of response, to a plug-in request. There are five types of failover scenarios for Web containers: Expected server process failures, for example after stopping the server. Unexpected server process failures, for example the server JVM crashes. Server network problems, for example the network cable is disconnected or a router is broken. Unexpected and expected system problems, for example a system shutdown, operating system crashes, or power failures. Overloading of Web clients, for example a denial of service attack, system is too small to handle a large number of clients, or server weight is inappropriate.

In the first two cases, the physical machine where the Web container is supposed to be running will still be available, although the Web container port will not be available. When the plug-in attempts to connect to the Web container port to process a request for a Web resource, the machine will refuse the connection, causing the plug-in to mark the appserver as down.

In the third and fourth events, however, the physical machine is no longer available to provide any kind of response. In these events, if non-blocking connection is not enabled, the plug-in will wait for the local operating system to time out the request before marking the appserver unavailable. While the plug-in is waiting for this connection to time out, requests routed to the failed application server appear to hang. The default value for the TCP timeout varies based on the operating system. While these values can be modified at the operating system level, adjustments should be made with great care. Modifications may result in unintended consequences in both WebSphere and other network dependent applications running on the machine. This problem can be eliminated by enabling non-blocking connection. Refer to ConnectTimeout setting for more information.

In the fifth case, client overloading can make a healthy server unavailable and cause a server overloading failover. This is explained in 9.2.4, Stream and overloading failover.

  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.