5.3.3 Configuring WebSphere Portal Server

Home

5.3.3 Configuring WebSphere Portal Server

With the eXtreme Scale infrastructure ready, configure the Portal Server to offload session management to the eXtreme Scale grid, as shown in Figure 5-10.

Figure 5-10 Configuring Portal Server with eXtreme Scale
To configure the Portal application servers to use the eXtreme Scale grid for session management, pass the session manager configuration parameters for the application to the session manager. These parameters can be in the form of servlet context initialization parameters in the deployment descriptors. However, when running in the WebSphere Portal Server environment, you do not need to do this manually for the applications. Instead, you can use the splicer.properties file to hold the configuration and define the file to the application servers with custom properties. The custom properties include:

The wps,com.ibm.websphere.xs.sessionFilterProps property, which is set to the location of the splicer.properties file.

For each custom portlet, define the Application_Name,com.ibm.websphere.xs.sessionFilterProps property and set it to the location of splicer.properties file.

Important: The administrative portlets that come with WebSphere Portal Server are not all serializable, so they cannot be persisted and should not be included in the applications that get spliced. If you specify the property com.ibm.websphere.xs.sessionFilterProps (without the application name) and set its value to the location of the splicer.properties file, Portal will try to splice all portlets including the administrative portlets, which can impact the way the environment performs.

The steps to configure the splicer.properties file and configure the application server to use them are...

1. The splicer.properties file contains all the configuration options for a servlet-filter-based grid session manager. Follow these steps to add this file to WebSphere Portal Server:

a. Locate the splicer.properties file in the following folder: WAS_HOME\optionalLibraries\ObjectGrid\session\samples

b. Modify the values. Most values in this file will work using the default values. However, we will need to define the variables as shown in Example 5-9.

Example 5-9 splicer.properties file for session management

# A string value of either "REMOTE" or "EMBEDDED". The default is REMOTE.
# If it is set to "REMOTE", the session data will be stored outside of
# the server on which the web application is running. If it is set to
# "EMBEDDED", an embedded WebSphere eXtreme Scale container will start
# in the application server process on which the web application is running.
objectGridType = REMOTE
# A string value that defines the name of the ObjectGrid
# instance used for a particular web application. The default name
# is session. This property must reflect the objectGridName in both
# the objectgrid.xml and deployment.xml files used to start the eXtreme
# Scale containers.
objectGridName = session
# Catalog Server can be contacted to obtain a client side
# ObjectGrid instance. The value needs to be of the
# form "host:port<,host:port>", where the host is the listener host
# on which the catalog server is running, and the port is the listener
# port for that catalog server process.
# This list can be arbitrarily long and is used for bootstrapping only.
# The first viable address will be used. It is optional inside WebSphere
# if the catalog.services.cluster property is configured.
catalogHostPort = saw006-sys2.itso.ral.ibm.com:9809,saw006-sys2.itso.ral.ibm.com:2809

Review and change the following settings as appropriate.

objectGridType

This variable can take a string value of EMBEDDED or REMOTE. It indicates whether the eXtreme scale grid container to be started is embedded inside the Portal Server process or is remote. In our sample environment the grid container was configured as REMOTE.

objectGridName

This variable takes a string value used by Portal to identify which grid in the grid container is to be used. Note that this name should match the objectGridName specified in the objectGridStandAlone.xml and objectGridDeploymentStandAlone.xml files.

catalogHostPort

Specifies the catalog server connection information. The value of this variable has to be of the form host:port,host:port, where the host is the listener on which the catalog server is running and port is the listener port for that catalog server process. This list can be any length and the first viable address is used.

In our sample setup, because there are two instances of catalog servers, one on the deployment manager and one on the node agent, that we have to specify both in the splicer.properties file. The catalog servers listen on the BOOTSTRAP_ADDRESS of the server. By default, the BOOTSTRAP_ADDRESS of the deployment manager profile is 9809 and that of the node agent is 2809. All catalog servers need to be started at approximately the same time.

There are few more variables in splicer.properties that you might want to consider changing:

replicationInterval

An integer that defines the time in seconds between updated sessions being written to the grid. 0 means updated sessions are written to the grid at the end of the servlet service method call for each request.

sessionTableSize

An integer value that defines the number of session references kept in memory.

Important: The number of sessions kept in memory must be a value greater than the maximum web container thread pool setting (default 50). Otherwise the web container threads will be bottlenecked by the in-memory session cache. The default of the sessionTableSize setting is 2000, but it should be set to a number that makes sense for the specific deployment based on the application server heap settings and the average HTTP session size. The in-memory sessions are kept in an least recently used (LRU) cache, so after the number of sessions in the web container is higher than sessionTableSize, the least recently used session is invalidated from the web container, but the session data is still stored in the remote eXtreme Scale container. A subsequent request for this session will actually create a new HTTP session, and the previous session's data will be loaded into the newly created session.

fragmentedSession

Takes a value of true or false to control whether session data is stored as a whole entry or each attribute separately.

securityEnabled

Takes a value of true or false to enable or disable eXtreme Scale client security. This setting needs to match the securityEnabled setting in the eXtreme Scale server properties file. If the settings do not match, an exception occurs.

2. Next, add the splicer.properties file to the Portal application server.

a. In the administrative console, click Server Ć Server Types Ć WASs and select the Portal server.

b. On the right side of the page, under Server Infrastructure click Administration Ć Custom Properties.

c. Click New.

d. Enter the following:

Name: wps,com.ibm.websphere.xs.sessionFilterProps

Value: Location of the splicer.properties file.

e. Click Apply and go back to the Custom Properties page.

f. Click New.

g. Enter the following:

Name: YourPortletName,com.ibm.websphere.xs.sessionFilterProps

Value: Location of the splicer.properties file

To know the exact name of the custom Portlet as recognized by Portal, on the administrative console, click Server Ć Server Types Ć WebSphere application servers Ć WebSphere_Portal. On the right side, under Applications, click Installed applications. This lists all of the applications installed on the Portal Server.

h. Click Apply and save the changes.

i. Repeat these steps for all the custom portlets. The Custom Properties page should look as shown in Figure 5-11.

Figure 5-11 Custom properties for splicing custom portlets on the Portal application server

3. Add session timeout settings.

The timeout.resume.session parameter is not included in the ConfigService.properties file and by default the WAS administration equates this parameter to false. Therefore, if an idle session timeout is experienced, a user will see the ErrorSessionTimeout window and be forced to re-login. The login causes a new session to be created.
Set the timeout.resume.session property to true. By default, Portal will verify the session ID for an active user, and if the session ID changes, the application will require a re-login by the user. Because a user session can change when that session is invalidated from the session cache, this value needs to be true when using eXtreme Scale for session persistence.
To add the timeout.resume.session property to the Portal Server do the following:

a. On the WebSphere administrative console, click Resources Ć Resource Environment Ć Resource Environment Providers.

b. Open WP ConfigService and click Custom Properties.

c. Click New and create a custom property with the name timeout.resume.session and the value true, as shown in the Figure 5-12

Figure 5-12 Session timeout settings on Portal Server

d. Click Apply and save the changes.

4. Restart the Portal Server.

+
Search Tips | Advanced Search