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
Overview
HttpSession passivation is configured in your application's WEB_INF/jboss-web.xml
or META_INF/jboss-web.xml
file.
Example 10.3. jboss-web.xml
File
<!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
<max-active-sessions>
- 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-1
sets no limit on the maximum number of active sessions. <passivation-config>
- This element holds the rest of the passivation configuration parameters, as child elements.
<passivation-config>
Child Elements
<use-session-passivation>
- Whether or not to use session passivation. The default value is
false
. <passivation-min-idle-time>
- 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
-1
disables passivating sessions before<passivation-max-idle-time>
has elapsed. Neither a value of -1 nor a high value are recommended if<max-active-sessions>
is set. <passivation-max-idle-time>
- 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 theweb.xml
. The default value of-1
disables passivation based on maximum inactivity.
Note
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 REPL
or DIST
cache mode is enabled. In REPL
cache mode, each session is replicated to each node. In DIST
cache mode, each session is replicated only to the number of nodes specified by the owners
parameter. 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
REPL
cache mode, each node would store 800 sessions in memory. With DIST
cache mode enabled, and the default owners
setting of 2
, each node stores 200 sessions in memory.