Show
all
Passivation allows a requestor, service, or clipboard page to be saved
into the PegaRULES database and reactivated later. A background process
known as the passivation daemon converts the in-memory state and
clipboard information into database rows, making the memory available for
other uses. The reverse process is known as activation.
Passivation is controlled through prconfig.xml
settings.
The passivation daemon wakes once a minute to handle passivations.
Passivation occurs through three distinct mechanisms:
- Page passivation — individual pages, Threads or entire
requestors
- Timeout passivation — entire requestors
- HTTP passivation at interaction end — to free JVM memory and support failover
Passivation frees up JVM memory, making more memory available to other
requestors. In addition, Timeout passivation has security benefits, and
HTTP passivation has failover benefits.
Idle pages within an otherwise active requestor
session may indicate a design or implementation issue that merits
research. Ensure that your processing creates only pages that are needed,
and removes them when they are no longer needed.
Where passivation
information is saved
Passivation details can be saved either as disk files on each
Process Commander server, or as database rows in the PegaRULES
database. Which option you choose affects which passivation features
are possible.
File System
By default, passivation details are saved as files on each Process
Commander server. This corresponds to the following
prconfig.xml
file setting:
<env
name="initialization/persistrequestor/storage"
value="file system" />
The saved information is converted to Java serialization file (SER
file type) in a directory named PassivationData, a subdirectory
of the temporary files directory. For performance reasons, files are
distributed in up to 36 subdirectories of this directory.
On a large system, ensure
that adequate disk space is available for these files. Optionally, you
can use tactics such as disk striping and RAID over multiple disks for
maximum performance. Through a symbolic link, you can place this
directory on a dedicated high-performance disk or disk array.
PegaRULES database
In releases before V5.5, passivation details are saved in the
PegaRULES database. This is no longer the default for V5.5+.
To save passivation details in the database rather than the server
file system, add the following setting to the
prconfig.xml
file.
<env
name="initialization/persistrequestor/storage"
value="database" />
When this option is set, the passivation daemon saves requestor
information as an instance of the
System-Requestor-Context class, corresponding to the
pr_sys_context
database table. The daemon saves page
details as an instance of the System-SavedPages class in
the pr_page_store
database table.
To recover database space, the system automatically purges pages
saved through this mechanism after three days.
Page
passivation
When a requestor creates a page but does not access it for a long
period, the passivation daemon may passivate the page class, and
remove it from the clipboard. Other pages for that requestor remain in
memory; requestor processing can continue normally until that page is
needed (for read access or for update). On demand, the page is
reactivated into memory. GRP-361
Similarly, when an entire Thread or requestor is inactive, the
Thread context or requestor context can be passivated (including the
associated clipboard pages).
By default, the passivation daemon passivates: SDAS
3/5/09
- Pages that are idle for at least 15 minutes
- Threads that are idle for at least 30 minutes, and
- Requestors that are idle for at least 60 minutes
Typically, page passivation improves performance for production
systems that may have 50 or more simultaneously connected requestors
(not counting agents). For smaller systems (with adequate JVM memory),
the benefits may be small or nil.
To disable page passivation, add the following element to
the prconfig.xml
file:
<env
"initialization/persistrequestor/usepagelevelpassivation"
value="false" />
Timeout
passivation
When enabled (through Initialization/PersistRequestor
settings in the prconfig.xml
file), each HTTP requestor
session can be saved after a specific time period of no activity.
To enable timeout passivation, use the following
prconfig.xml
setting:
<env
name="Initialization/PersistRequestor"
value="OnTimeout"/>
To prevent timeout passivation, use the Never
value:
<env
name="Initialization/PersistRequestor"
value="Never"/>
If the PersistRequestor
element is not present, the
system assumes OnTimeout
.
Passivated users are not automatically required to reauthenticate upon activation. The V4.X setting Initialization/NoAuthenticateOnActivate
defaults to true for V5.5 systems. As a best practice, do not override this default setting; other mechanisms may cause users to be prompted for credentials. SharePoint clinic 7/13/09
Passivation at HTTP
interaction end
In a multinode cluster (with appropriate configuration),
requestor passivation can promote high availability and load balancing
across nodes, since the reactivated session can resume on a different
node than the node that previously supported the user. (The previous
node may be down or busy.)
Passivation also frees JVM memory, making more memory available to other requestors.
To support this capability, add the following elements to the
prconfig.xml
file:
<env
name="initialization/persistrequestor/storage"
value="database" />
<env
name="Initialization/PersistRequestor"
value="AtInteractionEnd"/>
The system saves requestor state and user pages into the PegaRULES
database at the end of each user interaction. This provides
potentially higher availability, but with greater overhead. Each user interaction with the browser may involve multiple HTTP
messages and responses from the server. To minimize overhead, the
passivation daemon attempts to passivate only after the final HTTP
response in a series (which is determined by observing a 30-second pause).
HTTP passivation to support failover in a cluster can occur only when
passivation details are saved to the PegaRULES database, rather than
the file system. SDAS 3/5/09
For IAC users, who access a Process Commander application through a web node, passivation occurs at HTTP interaction end occurs always. The value of the Initialization/PersistRequestor
setting does not affect these users. CLINB clinic 7/13/09
Troubleshooting
long-lived pages
Clipboard pages that remain unused for long
periods may indicate a design or implementation flaw that can hurt
performance; the application created a page but neglected to use the
Page-Remove method to remove the page after it was no longer
needed.
When building or testing an application, you can discover whether
your own processing has created such "orphan" or
"near-orphan" page:
- Select from the Quick Launch area of the Designer Studio to start the Clipboard
tool.
- From the Action menu in the right panel, select
Analyze Clipboard.
- In the resulting grid of data, look in the Est Size
(KB), Last Passivation, and Last Activation
columns to identify any pages that were automatically passivated
but never reactivated.
- Research whether such pages are needed at all, and whether they
can be removed at specific points in the application, to reduce
clipboard size.
Reporting on
passivated requestors
To see a list of passivated requestors on the PegaRULES database,
open and run the standard list view report
System-Requestor-Context.RequestorContextList.ALL. This
information is also available from the System Management
Application:
- Select> System > Tools > System Management AppBYRNB 2/26/10 to
start the System Management Application.
- Select a server node.
- Select Advanced > Passivation Management. The 100
most recently passivated requestors appear at the bottom on the
right panel. DAS 12/8/2008
Notes
C-843 When a user exits a requestor session by logging
off, all user clipboard pages are erased, including any not saved to
the PegaRULES database by the Obj-Save method and Commit method are
erased. No passivation occurs.
Agent requestors have a BATCH
requestor type. They are
never passivated. BUG-3442
V4.2 includes an additional
PersistRequestor
value UseHTTPSession
.
This setting is not functional in V5.X. OLSOK CLINIC 9/5/08
SR-3127 B-20102
Concepts