17.2. HttpSession passivation and activation


The process of controlling memory usage by removing relatively unused sessions from memory while storing them in persistent storage.

If a passivated session is requested by a client, it can be "activated" back into memory and removed from the persistent store. JBoss Enterprise Application Platform 5 supports HttpSession passivation 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"


  • 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. Take this into account when setting max-active-sessions. Whether or not buddy replication is enabled will also affect the number of sessions replicated from other nodes.
    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.
  • passivation-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.
  • passivation-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.