Red Hat Training
A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform
10.2. HttpSession Passivation and Activation
10.2.1. About HTTP Session Passivation and Activation
Passivation is the process of controlling memory usage by removing relatively unused sessions from memory while storing them in persistent storage.
Activation is when passivated data is retrieved from persisted storage and put back into memory.
Passivation occurs at three different times in a HTTP session's lifetime:
- When the container requests the creation of a new session, if the number of currently active session exceeds a configurable limit, the server attempts to passivate some sessions to make room for the new one.
- Periodically, at a configured interval, a background task checks to see if sessions should be passivated.
- When a web application is deployed and a backup copy of sessions active on other servers is acquired by the newly deploying web application's session manager, sessions may be passivated.
A session is passivated if it meets the following conditions:
- The session has not been in use for longer than a configurable maximum idle time.
- The number of active sessions exceeds a configurable maximum and the session has not been in use for longer than a configurable minimum idle time.
Sessions are always passivated using a Least Recently Used (LRU) algorithm.
10.2.2. Configure HttpSession Passivation in Your Application
HttpSession passivation is configured in your application's
<!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 5.0//EN" "http://www.jboss.org/j2ee/dtd/jboss-web_5_0.dtd"> <jboss-web version="6.0" xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_6_0.xsd"> <max-active-sessions>20</max-active-sessions> <passivation-config> <use-session-passivation>true</use-session-passivation> <passivation-min-idle-time>60</passivation-min-idle-time> <passivation-max-idle-time>600</passivation-max-idle-time> </passivation-config> </jboss-web>
Passivation Configuration Elements
- The maximum number of active sessions allowed. If the number of sessions managed by the session manager exceeds this value and passivation is enabled, the excess will be passivated based on the configured
<passivation-min-idle-time>. Then, if the number of active sessions still exceeds this limit, attempts to create new sessions will fail. The default value of
-1sets no limit on the maximum number of active sessions.
- This element holds the rest of the passivation configuration parameters, as child elements.
<passivation-config> Child Elements
- Whether or not to use session passivation. The default value is
- The minimum time, in seconds, that a session must be inactive before the container will consider passivating it in order to reduce the active session count to conform to value defined by max-active-sessions. The default value of
-1disables passivating sessions before
<passivation-max-idle-time>has elapsed. Neither a value of -1 nor a high value are recommended if
- The maximum time, in seconds, that a session can be inactive before the container attempts to passivate it to save memory. Passivation of such sessions takes place regardless of whether the active session count exceeds
<max-active-sessions>. This value should be less than the
<session-timeout>setting in the
web.xml. The default value of
-1disables passivation based on maximum inactivity.
The total number of sessions in memory includes sessions replicated from other cluster nodes that are not being accessed on this node. Take this into account when setting
<max-active-sessions>. The number of sessions replicated from other nodes also depends on whether
DISTcache mode is enabled. In
REPLcache mode, each session is replicated to each node. In
DISTcache mode, each session is replicated only to the number of nodes specified by the
ownersparameter. See Section 10.1.2, “About the Web Session Cache” and Section 10.1.3, “Configure the Web Session Cache” for information on configuring session cache modes.
For example, consider an eight node cluster, where each node handles requests from 100 users. With
REPLcache mode, each node would store 800 sessions in memory. With
DISTcache mode enabled, and the default
2, each node stores 200 sessions in memory.