Recall that when you use IHS (IBM HTTP Server, which is based on the Apache Web Server), or any of the WebSphere supported WebServers, there is a component call the "plug-in" whose job it is to route request that come to IHS forward to the WebSphere Application Server or WebSphere Portal Server as appropriate.
One of the features of the plug-in is to load balance inbound requests to the cluster members (a.k.a "servers" or JVMs) of the Portal/WAS cluster. The plug-in maintains session affinity, as appropriate, for all these inbound requests so that once a session is bound, it always routes to that cluster member. If a cluster member fails, the plug-in is responsible for detecting that failure and re-routing the inbound requests to another cluster member.
In the past, if a cluster member failed, the plug-in simply moved all the sessions currently bound to the failing cluster member(s) to the next available cluster member. Since this could result in a flood of new sessions to the "next available cluster member", a situation called "cascade failure" could occur since that one cluster member could receive a flood of new requests (all requiring a new session be set up). This large peak in requests bound to a single cluster member could cause a failure itself.
A much more desirable behavior would be for the plug-in to distribute all the sessions bound to the failing server evenly to the surviving cluster members.
This new behavior is avail with the plug-in fixpack available in either WAS 220.127.116.11 or WAS 18.104.22.168.
Here's technote that give further information on the plugin configuration that I find useful: Understanding IBM HTTP Server plug-in Load Balancing in a clustered environment