Configuring the HTTP session manager with WebSphere Application Server
While WebSphere® Application Server provides session management function, the performance degrades as the number of requests increases. WebSphere eXtreme Scale comes bundled with a session management implementation that provides session replication, high availability, better scalability, and more robust configuration options.
Before you begin
- WebSphere eXtreme Scale must be installed on your WebSphere Application Server or WebSphere Application Server Network Deployment cell to use the eXtreme Scale session manager. For more information, see Installing WebSphere eXtreme Scale or WebSphere eXtreme Scale Client with WebSphere Application Server.
- When WebSphere eXtreme Scale for HTTP session replication is used on WebSphere Application Server, the Allow overflow session management setting must be checked for every applicable web application and application server that hosts that web application. For more information, see Session management settings.
- Global security must be enabled in the WebSphere Application Server administrative console, if the catalog servers within your catalog service domain have Secure Sockets Layer (SSL) enabled. It must also be enabled if you want to use SSL for a catalog service domain with SSL supported. You require SSL for a catalog server by setting the transportType attribute to SSL-Required in the Server properties file. For more information about configuring global security, see Global security settings.
- If you are connecting to WebSphere eXtreme Scale
servers that are configured for NIST SP800-131a compliance, then you need to configure WebSphere Application Server for NIST SP8000-131a compliance as well:
- To configure WebSphere Application Server for standard transition mode, see Transitioning WebSphere Application Server to the SP800-131 security standard.
- To configure WebSphere Application Server for strict mode, see Configuring WebSphere Application Server for SP800-131 standard strict mode.
About this task
In the embedded scenario, the data grid servers are collocated in the same processes where the servlets run. The session manager can communicate directly with the local ObjectGrid instance, avoiding costly network delays.
If you are using WebSphere Application Server, place the supplied wxs_home/session/samples/objectGrid.xml and wxs_home/session/samples/objectGridDeployment.xml files into the META-INF directories of your web archive (WAR) files. eXtreme Scale automatically detects these files when the application starts and automatically starts the eXtreme Scale containers in the same process as the session manager.
You can modify the objectGridDeployment.xml file. Modifying this file depends on whether you want to use synchronous or asynchronous replication and how many replicas you want configured.
Remote servers scenario
In the remote servers scenario, the container servers that are run are in different processes than the servlets. The session manager communicates with a remote container server. To use a remote, network-attached container server, the session manager must be configured with the host names and port numbers of the catalog service domain. The session manager then uses an eXtreme Scale client connection to communicate with the catalog server and the container servers.
If the container servers are starting in independent, stand-alone processes, start the data grid containers with the objectGridStandAlone.xml and objectGridDeploymentStandAlone.xml files that are supplied in the session manager samples directory.
- Splice your application so that it can use the session manager. To use the session manager, you must add the appropriate filter declarations to the web deployment descriptors for the application. In addition, session manager configuration parameters are passed in to the session manager in the form of servlet context initialization parameters in the deployment descriptors. There are multiple ways in which you can introduce this information into your application:
For a list of the parameters that you can use, see Servlet context initialization parameters.
- Auto-splice with WebSphere Application Server
You can configure your application to use the HTTP session manager for the data grid when you install your application. You can also edit the application or server configuration to use the WebSphere eXtreme Scale HTTP session manager. For more information, see Configuring WebSphere Application Server HTTP session persistence to a data grid.
- Splice the application with the addObjectGridFilter script
For more information about running this script, see Splicing a session data grid application with the addObjectGridFilter script.
- Auto-splice the application with custom properties
You do not need to manually splice your applications when the application is running in WebSphere Application Server or WebSphere Application Server Network Deployment.You can use this auto-splice option when your environment meets the following conditions:
- You are using a deployment manager. The cell, server, and application scope are available scopes and are only available when you are running in a deployment manager. If you require a different scope, manually splice your web applications.
- The splicer.properties file must be in at the same path on all nodes. The nodes are hosting an application server or applications that are being spliced for session replication. For mixed environments containing Windows and UNIX nodes, this option is not possible, so you must manually splice the application.
Add the com.ibm.websphere.xs.sessionFilterProps custom property to either a cell or a server to set the splicer.properties file location for all of the web applications at that scope. The file exists on the deployment manager. If you want to indicate the splicer.properties file for a specific application with a cell-level custom property, enter the name of the custom property as: <application_name>,com.ibm.websphere.xs.sessionFilterProps, where application_name indicates the name of the application for which you want to apply the custom property. The value is the location of the splicer.properties file your applications require. An example path for the location of a file follows: /opt/splicer.properties.
- Manually splice the application with the Ant build scriptWebSphere eXtreme Scale ships with a build.xml file that can be used by Apache Ant, which is included in the was_root/bin folder of a WebSphere Application Server installation. You can modify the build.xml file to change the session manager configuration properties. The configuration properties are identical to the property names in the splicer.properties file. You modify the build.xml file, start the Ant process by running the following command:
- ant.sh, ws_ant.sh
- ant.bat, ws_ant.bat
- Manually update the web descriptor
Edit the web.xml file that is packaged with the web application to incorporate the filter declaration, its servlet mapping, and servlet context initialization parameters. Do not use this method because it is prone to errors.
- Auto-splice with WebSphere Application Server
- Deploy the application. Deploy the application with your normal set of steps for a server or cluster. After you deploy the application, you can start the application.
- Access the application. You can now access the application, which interacts with the session manager and WebSphere eXtreme Scale.
What to do next
- A network problem between the web container and the remote container servers.
- The remote container server processes have been stopped.