Installation guide

from clustered web applications where the web.xml file includes the distributable directive.
Passivation occurs at three points during the life cycle of a web application:
When the container requests the creation of a new session. If the number of currently active
sessions exceeds a configurable limit, an attempt is made to passivate sessions to make room in
memory.
Periodically (by default every ten seconds) as the JBoss Web background task thread runs.
When the 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.
A session is passivated if one of the following conditions is true:
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.
In both cases, sessions are passivated on a Least Recently Used (LRU) basis.
17.2.1. Configuring HttpSession passivation
Session passivation behavior is configured in the jboss-web.xml deployment descriptor in your web
application's WEB-INF directory.
<!DOCTYPE jboss-web PUBLIC
"-//JBoss//DTD Web Application 5.0//EN"
"http://www.jboss.org/j2ee/dtd/jboss-web_5_0.dtd">
<jboss-web>
<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>
max-active-sessions
Determines 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. If after passivation is completed (or if
passivation is disabled), the number of active sessions still exceeds this limit, attempts to create new
sessions will be rejected. If set to -1 (the default), there is no limit.
The total number of sessions in memory includes sessions replicated from other cluster nodes that
are not being accessed on this node. T ake this into account when setting max-active-sessions.
The number of sessions replicated from other nodes will also depend on whether buddy replication
is enabled.
Say, for example, that you have an eight node cluster, and each node handles requests from 100
users. With total replication, each node would store 800 sessions in memory. With buddy replication
enabled, and the default numBuddies setting (1), each node will store 200 sessions in memory.
use- session-passivation
Determines whether session passivation will be enabled for the web application. Default is false.
passiva tion-min- idle-time
Determines the minimum time (in seconds) that a session must have been inactive before the
container will consider passivating it in order to reduce the active session count to obey the value
defined by max-active-sessions. A value of -1 (the default) disables passivating sessions before
passivation-max-idle-time. Neither a value of -1 nor a high value are recommended if max-
active-sessions is set.
passiva tion-max-idle-time
Determines the maximum time (in seconds) that a session can be inactive before the container
should attempt to passivate it to save memory. Passivation of such sessions will take place
regardless of whether the active session count exceeds max-active-sessions. Should be less
than the session-timeout setting in web.xml . A value of -1 (the default) disables passivation
based on maximum inactivity.
17.3. Configure the JBoss Cache instance used for session state
replication
The container for a distributable web application makes use of JBoss Cache to provide HTT P session
replication services around the cluster. It integrates with the CacheManager service to obtain a
reference to a JBoss Cache instance. For more information, refer to the Distributed Caching with JBoss
Cache and JBoss Cache Configuration and Deployment chapters in the Administration and Configuration
Guide
70 Chapter 17. HTTP session state replication