However, this feature requires the support of the application code, so when the was cluster architecture is selected, the Http://www.aliyun.com/zixun/aggregation/14134.html "> Cluster deployment approach is determined according to the current application. and give professional advice. Architects and software engineers must be aware of the specifics of this feature in order to be more handy when designing a cluster architecture.
HTTP session memory replication refers to replicating a session to another application server. In this mode, the session can be replicated to one or more application servers to prevent the HTTP session from losing the impact on the end user due to the application server's single point of failure.
Through a virtual example, this article explains the content of the highly available features of the WebSphere creator Server cluster, "HTTP Session Memory Replication", illustrates the usage of this feature, and elaborates the requirements of the feature for application coding through simulated instance tests, That is, all objects put into session must be serializable (the Serializable interface should be implemented).
was cluster architecture for demonstration
This example uses a physical machine Server1 (ip:192.168.133.128)
Server1 deployed IBM HTTP Server (IHS1), IBM HTTP Server (IHS2), was node computerNode06 and was node computerNode07
Contains a was cluster CLU, where two cluster members are MEM1 (from computerNode06) and mem2 (from ComputerNode07).
The two HTTP server,ihs1 and ih2 compose the front layer, do the load balancing of the cluster, and for testing purposes, the external connection only accesses the IHS1, as shown in Figure 1.
Figure 1. was cluster topology
Virtual Scenarios for testing
This article uses a virtual scenario for highly available testing, simulating a user registration process, which is divided into the following steps, each of which is done in a separate WEB page.
Step 1: In this step the user must enter the username and age. Step 2: The user must enter a password in this step. Step 3: Registration is successful, the page displays the registration information (name and age) for user confirmation.
The application code is packaged and deployed to the Web Server and was cluster, and the context root is set to Sessionha.
To test for high availability, all subsequent requests from the customer are distributed to the same application server (that is, on the same cluster member) after the user enters the password and has not yet clicked the Submit button, because of the session Affinity feature of the cluster. Before manual downtime, you need to check the IBM HTTP Server's plug-in log file to identify the cluster members that need to be down, in order to be able to get enough information from the plug-in log, you need to be aware that the record level of the change plug-in log is Stats, and after the manual downtime, users click in step 2 The Submit button continues with the registration step to see if the registration step is correctly performed in step 3.
The test is divided into two parts
When a custom object is not included in a session: The program code saves the user name and age information entered by the user as a string in a session, and the code file that is used is as follows:
withoutcustomobject_register_step1.jsp
withoutcustomobject_register_step2.jsp
withoutcustomobject_register_success.jsp
Three steps corresponding to the virtual scene respectively.
When a custom object is included in a session: The program code stores the user name and age information entered by the user in the object of the Registerinformation class, Registerinformation is a user-defined class and does not implement the Serializable interface The code file used is as follows:
customobject_register_step1.jsp
customobject_register_step2.jsp
customobject_register_success.jsp
Three steps corresponding to the virtual scene respectively;
Registerinformation.java
Registers the information store class file.