Each HTTP session contains two pieces of information that determine when it has timed out. The first is the
LastAccessedTime property of the session, which is the time stamp of the most recent activity involving the session. The second is the
MaxInactiveInterval property of the session, which specifies how long the session is kept active without any activity; a typical value for this property is 30 minutes. The
MaxInactiveInterval property defaults to the value configured for Coherence*Web, but it can be modified on a session-by-session basis.
Each time that an HTTP request is received by the server, if there is an HTTP session associated with that request, then the
LastAccessedTime property of the session is automatically updated to the current time. As long as requests continue to arrive related to that session, it is kept active, but when a period of inactivity occurs longer than that specified by the
MaxInactiveInterval property, then the session expires. Session expiration is passive—occurring only due to the passing of time. The Coherence*Web Session Reaper scans for sessions that have expired, and when it finds expired sessions it destroys them.
This chapter includes the following sections:
Understanding the Session Reaper
Understanding Where the Session Reaper Runs
Every application server running Coherence*Web runs the Session Reaper. That means that if Coherence is configured to provide a separate cache tier (made up of cache servers), then the Session Reaper does not run on those cache servers.
By default, the Session Reaper runs concurrently on all of the application servers, so that all of the servers share the workload of identifying and cleaning up expired sessions. The
coherence-reaperdaemon-cluster-coordinated context parameter causes the cluster to coordinate reaping so that only one server at a time performs the actual reaping; the use of this option is not suggested, and it cannot be used with the Coherence*Web over Coherence*Extend topology.
coherence-reaperdaemon-cluster-coordinated context parameter should not be used if sticky optimization (
coherence-sticky-sessions) is also enabled. Because only one server at a time performs the reaping, sessions owned by other nodes cannot be reaped. This means that it will take longer for sessions to be reaped as more nodes are added to the cluster. Also, the reaping ownership does not circulate over the nodes in the cluster in a controlled way; one node can be the reaping node for a long time before it is taken over by another node. During this time, only its own sessions are reaped.
Understanding How Frequently the Session Reaper Runs
The Session Reaper is configured to scan the entire set of sessions over a certain period, called a reaping cycle, which defaults to five minutes. This length of the reaping cycle is specified by the
coherence-reaperdaemon-cycle-seconds context parameter. This setting indicates to the Session Reaper how aggressively it must work. If the cycle length is configured too short, the Session Reaper uses additional resources without providing additional benefit. If the cycle length is configured too long, then expired sessions will use heap space in the Coherence caches unnecessarily. In most situations, it is far preferable to reduce resource usage than to ensure that sessions are cleaned up quickly after they expire. Consequently, the default cycle of five minutes is a good balance between promptness of cleanup and minimal resource usage.
During the reaping cycle, the Session Reaper scans for expired sessions. In most cases, the Session Reaper takes responsibility for scanning all of the HTTP sessions across the entire cluster, but there is an optimization available for the single tier topology. In the single tier topology, when all of the sessions are being managed by storage-enabled Coherence cluster members that are also running the application server, the session storage is colocated with the application server. Consequently, it is possible for the Session Reaper on each application server to scan only the sessions that are stored locally. This behavior can be enabled by setting the
coherence-reaperdaemon-assume-locality configuration option to
Regardless of whether the Session Reaper scans only colocated sessions or all sessions, it does so in a very efficient manner by using these advanced capabilities of the Coherence data grid:
The Session Reaper delegates the search for expired sessions to the data grid using a custom
ValueExtractortakes advantage of the
BinaryEntryinterface so that it can determine if the session has expired without even deserializing the session. As a result, the selection of expired sessions can be delegated to the data grid just like any other parallel query, and can be executed by storage-enabled Coherence members in a very efficient manner.
The Session Reaper uses the
com.tangosol.net.partition.PartitionedIteratorclass to automatically query on a member-by-member basis, and in a random order that avoids harmonics in large-scale clusters.
Each storage-enabled member can very efficiently scan for any expired sessions, and it has to scan only one time per application server per reaper cycle. The result is a default Session Reaper configuration that works well for application server clusters with one or multiple servers.
Understanding How the Session Reaper Runs
Coherence*Web uses a work manager to retrieve threads to execute the parallel reaping. WebLogic Server defines a default work manager,
wm/CoherenceWorkManager, which it will attempt to use. If no work manager is defined with that name, it will use the default work manager implemented in Coherence.
To use the default WebLogic Server work manager, use the WebLogic Server Administration Console to create a work manager that is named
wm/CoherenceWorkManager. Also, add the following
resource-ref element in the application
<resource-ref> <res-ref-name>wm/CoherenceWorkManager</res-ref-name> <res-type>commonj.work.WorkManager</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Shareable</res-sharing-scope> </resource-ref>
To ensure that the Session Reaper does not impact the smooth operation of the application server, it breaks up its work into chunks and schedules that work in a manner that spreads the work across the entire reaping cycle. Because the Session Reaper has to know how much work it must schedule, it maintains statistics on the amount of work that it performed in previous cycles, and uses statistical weighting to ensure that statistics from recent reaping cycles count more heavily. There are several reasons why the Session Reaper breaks up the work in this manner:
If the Session Reaper consumed a large number of CPU cycles simultaneously, it could cause the application to be less responsive to users. By doing a small portion of the work at a time, the application remains responsive.
One of the key performance enablers for Coherence*Web is the near-caching feature of Coherence; because the sessions that are expired are accessed through that same near cache to clean them, expiring too many sessions too quickly could cause the cache to evict sessions that are being used on that application server, leading to performance loss.
The Session Reaper performs its job efficiently, even with the default configuration by:
Delegating as much work as possible to the data grid
Delegating work to only one member at a time
Enabling the data grid to find expired sessions without deserializing them
Restricting the usage of CPU cycles
Avoiding cache-thrashing of the near caches that Coherence*Web relies on for performance
Understanding How the Session Reaper Removes Sessions
The Session Reaper can invalidate sessions either in parallel or serially. By
default, it invalidates sessions serially, which may be useful if the application server
JVM has a high system load due to a large number of concurrent threads. To invalidate
sessions in parallel, set the
The Session Reaper deletes sessions that have timed-out. The default behavior is to remove the session after fetching it from the local JVM and calling the
invalidate method on the HTTP session. However, the session reaper can also be configured to delete sessions remotely using a Coherence entry processor. In this case, the
invalidate method of the HTTP session and the session listeners are not invoked. Deleting sessions remotely is much faster than the default mechanism but should only be used in applications that do not use session listeners. To configure the reaper to delete sessions remotely, set the
coherence-session-reaping-mechanism context parameter to
Tuning the Session Reaper
To tune the default Session Reaper configuration:
If the application is deployed with the in-process topology, then set the
coherence-reaperdaemon-assume-localityconfiguration option to
Because all of the application servers are responsible for scanning for expired sessions, it is reasonable to increase the
coherence-reaperdaemon-cycle-secondsconfiguration option if the cluster is larger than 10 application servers. The larger the number of application servers, the longer the cycle can be; for example, with 200 servers, it would be reasonable to set the length of the reaper cycle as high as 30 minutes (that is, setting the
coherence-reaperdaemon-cycle-secondsconfiguration option to 1800).
If the application does not use session listeners, then set the
coherence-session-reaping-mechanismcontext parameter to
Getting Session Reaper Performance Statistics
HttpSessionManagerMBeanWebprovides performance statistics for monitoring the average time duration for a reap cycle, the number of sessions reaped, and the time until the next reap cycle.
The following performance statistics are available for the Session Reaper:
AverageReapDuration, which is the average reap duration (the time it takes to complete a reap cycle), in milliseconds, since the statistic was reset
LastReapDuration, which is the time in milliseconds it took for the last reap cycle to finish
MaxReapedSessions, which is the maximum number of sessions reaped in a reap cycle since the statistic was reset
NextReapCycle, which is the time (as a
java.lang.Datedata type) for the next reap cycle
ReapedSessions, which is the number of sessions reaped during the last cycle
ReapedSessionsTotal, which is the number of expired sessions that have been reaped since the statistic was reset
You can access these attributes in a monitoring tool such as JConsole. However, you must set up the Coherence Clustered JMX Framework before you can access them. See Using JMX to Manage Coherence in Managing Oracle Coherence.
Understanding Session Invalidation Exceptions for the Session Reaper
Session attribute listeners are registered with the Web application that is reaping expired sessions. The listeners attempt to retrieve the session attribute values during invalidation. If the session attributes are dependent on classes that exist only in the original Web application, then a class not found exception is thrown and logged in the Session Reaper. These exceptions will not cause any disruption in the Web application or the application server.
Coherence*Web provides a context parameter,
coherence-session-log-invalidation-exceptions, to control whether these exceptions are logged. The default value,
true, allows the exceptions to be logged. If you want to suppress the logging of these exceptions, set this context parameter to