|
|
As you know, the plug-in always attempts to route a request that contains session information to the appserver that processed the previous requests. However, if 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).
There are three methods of identifying a user's session to the appserver: Cookies, URL rewriting, and SSL ID. Example 2-1 shows a JSESSIONID cookie which consists of four parts:
| Cache ID (0000) |
|
| Session ID (A2MB4IJozU_VM8IffsMNfdR) |
|
| Separator (:) |
|
| Clone ID (v544d0o0 = appserver ID) |
Example 2-1 Example of a session identifier - JSESSIONID cookie
JSESSIONID=0000A2MB4IJozU_VM8IffsMNfdR:v544d0o0
In case of a failover, the Clone ID of the failover server is appended at the end, also separated by a colon. When the original server becomes available again, the request falls back and is handled by the original server.
Figure 2-6 and the subsequent step-by-step explanation explain how the plug-in performs the failover.
Figure 2-6 Session management example
Using Figure 2-6, the steps involved to find a failover appserver are:
1. The plug-in processes a request from user A to http://http1/snoop. The request also contains a JSESSION cookie with a session ID and Clone ID of v544d031.
| 2. | The plug-in matches the virtual host and URI to the cluster wascluster01 (composed by servers wasmember01 and wasmember03, each one located in a different machine). |
| 3. | The plug-in checks for session affinity and finds the Clone ID of v544d031 in the request's JSESSIONID cookie. |
| 4. | The plug-in searches for the Clone ID of v544d031 in the plug-cfg.xml's list of primary servers and matches the Clone ID to the wasmember01 appserver. |
| 5. | The plug-in checks to see if wasmember01 has been marked down. In our case, it has not been marked down yet. |
| 6. | The plug-in attempts to get a stream to wasmember01. Finding the server is not responding, Web1 is marked as down and the retry timer is started. |
| 7. | The plug-in checks the session identifier again. |
| 8. | The plug-in checks the servers. When it reaches wasmember01, it finds it is marked down and the retry timer is not 0, so it skips wasmember01 and checks the next cluster member in the primary server list. |
| 9. | The plug-in selects wasmember03 (Clone ID v544d0o0) and 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 wasmember03 (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. |
For additional information about plug-in failover behavior, read "WebSphere plug-in behavior" in Chapter 6 of IBM WebSphere V6 Scalability and Performance Handbook, SG24-6392. This section discusses many failure situations in detail and includes information about logs and traces.
