Fusion Middleware Documentation
Advanced Search


Administering HTTP Session Management with Oracle Coherence*Web
Close Window

Table of Contents

Show All | Collapse

7 Cleaning Up Expired HTTP Sessions

This chapter describes how to configure and use the Session Reaper. The Session Reaper is responsible for destroying any session that is no longer used, which is determined by when that session has timed out.

This chapter contains the following sections:

As part of Coherence*Web Session Management Module, HTTP sessions that have expired are eventually cleaned up by the Session Reaper. The Session Reaper provides a service similar to the JVM Garbage Collection (GC) capability: the Session Reaper is responsible for destroying any session that is no longer used, which is determined by when that session has timed out.

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.

7.1 Understanding the Session Reaper

The Session Reaper configuration addresses three basic questions:

  • On which servers will the Reaper run?

  • How frequently will the Reaper run?

  • When the Reaper runs, on which servers will it look for expired sessions?

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.

The 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.

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 true.

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 ValueExtractor implementation. This ValueExtractor takes advantage of the BinaryEntry interface 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.PartitionedIterator class 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.

The Session Reaper can invalidate sessions either in parallel or serially. By default, it invalidates sessions in parallel. This ensures that sessions are invalidated in a timely manner. However, if the application server JVM has a high system load due to a large number of concurrent threads then you have the option of invalidating serially. To configure the reaper to invalidate sessions serially, set the coherence-reaperdaemon-parallel context parameter to false.

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 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

7.2 Configuring the Session Reaper

The following are suggestions for tuning the default Session Reaper configuration:

  • If the application is deployed with the in-process topology, then set the coherence-reaperdaemon-assume-locality configuration option to true.

  • Because all of the application servers are responsible for scanning for expired sessions, it is reasonable to increase the coherence-reaperdaemon-cycle-seconds configuration 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-seconds configuration option to 1800).

7.3 Getting Session Reaper Performance Statistics

The HttpSessionManagerMBeanWeb provides several attributes that serve as performance statistics for the Session Reaper. These statistics, described in the following list, include the average time duration for a reap cycle, the number of sessions reaped, and the time until the next reap cycle:

  • 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.Date data 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

These attributes are also described in Table 6-2 in the section "Managing and Monitoring Applications with JMX".

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. The configuration and installation instructions for the framework is provided in "Using JMX to Manage Coherence" in Oracle Fusion Middleware Managing Oracle Coherence.

7.4 Understanding Session Invalidation Exceptions for the Session Reaper

Each Coherence*Web instance has a Session Reaper that will periodically iterate through all of the sessions in the session cache and check for expired sessions. If multiple Web applications are using Coherence*Web, then a reaper from one Web application can invalidate sessions used in a different application. Session listeners registered with the Web application that is reaping expired sessions will be executed.

Session attribute listeners will 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 will be 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 false.