6.8.3 Session management and failover inside the plug-in

 

+

Search Tips   |   Advanced Search

 

The plug-in will always try and route a request that contains session information to the appserver that processed the previous requests. If however the server that contains the session is not available to the plug-in when it forwards the request, then the plug-in can route the request to an alternate server. The alternate server can then retrieve the distributed session information according to the chosen distribution method (database or memory-to-memory replication).

Using Figure 6-28, the steps involved using our sample topology are:

  1. The plug-in processes a request from user A to...

    http://OurWebServer/snoop

    The request also contains a JSESSION cookie with a session ID and CloneID of v544d031.

  2. The plug-in matches the virtual host and URI to the cluster WEBcluster, composed of servers Web1 and Web2a, each one located in a different machine.

  3. The plug-in then checks for session affinity and finds the CloneID of v544d031 in the request's JSESSIONID cookie.

  4. It then searches for the CloneID of v544d031 in the plug-cfg.xml's list of primary servers and matches the CloneID to the Web1 appserver.

  5. The plug-in will then check to see if Web1 has been marked down. In our case it has not been marked down yet.

  6. It then attempts to get a stream to Web1. Finding the server is not responding, Web1 is marked as down and the retry timer is started.

  7. The plug-in then checks the session identifier again.

  8. It then checks the servers. When it reaches Web1, it finds it is marked down and the retry timer is not 0, so it skips Web1 and checks the next cluster member in the primary list.

  9. Web2a (CloneID v544d0o0) is selected and the plug-in attempts to get a stream to it. The plug-in either opens a stream or gets an existing one from the queue.

  10. The request is sent and received successfully to Web2a, which retrieves the session information from the persistent session database or has it in-memory because of a previous replication, and sent back to user A.

The following sections explain the configuration steps needed to enable distributed session management using either a database or memory-to-memory replication.

Next