6 Cleaning Up Expired HTTP Sessions

The Coherence*Web Session Management Module includes a Session Reaper that is responsible for removing HTTP sessions that have expired.You should monitor the Session Reaper and ensure that it is properly configured based on your application and deployment environment. Properly managing the Session Reaper can help minimize resource usage and can help increase performance.

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
  The Session Reaper configuration addresses basic questions such as how frequently will the reaper run, on which servers will the reaper run, and on which servers will it look for expired sessions.
• Tuning the Session Reaper
  There are several Session Reaper configuration properties that can be changed based on how your application is implemented and deployed.
• Getting Session Reaper Performance Statistics
  The HttpSessionManagerMBeanWeb provides 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.
• Understanding Session Invalidation Exceptions for the Session Reaper
  If multiple Web applications are using a Coherence*Web instance, then a reaper from one Web application can invalidate sessions used in a different application.

Understanding the Session Reaper

The Session Reaper configuration addresses basic questions such as how frequently will the reaper run, on which servers will the reaper run, and on which servers will it look for expired sessions.

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.

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.

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

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.

The default Coherence work manager implementation uses the java.util.concurrent.ThreadPoolExecutor Java API to process the submitted tasks using one of the many threads in the pool. A blocking queue such as LinkedBlockingQueue, is used to schedule the waiting tasks in the order of first-in-first out (FIFO).

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 web.xml file:

<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 coherence-reaperdaemon-parallel context parameter to true.

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

Tuning the Session Reaper

There are several Session Reaper configuration properties that can be changed based on how your application is implemented and deployed.

To tune 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).

• If the application does not use session listeners, then set the coherence-session-reaping-mechanism context parameter to RemoteDelete.

• If you want to set the queue size of the Session Reaper work manager, use the coherence-reaperdaemon-queue-size configuration option. If not set, the queue size is unlimited. This option is used only when parallel reaping is enabled and is not applicable for Service Provider Interface (SPI).

• If you want to set the maximum number of threads for the Session Reaper daemon, use the coherence-reaperdaemon-max-threads configuration option. The default value for this option is 5.

• If you want to set the Configuration parameter for minimum number of threads for the Session Reaper daemon, use the coherence-reaperdaemon-min-threads configuration option. The default value for this option is 1.

Getting Session Reaper Performance Statistics

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

See 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. See Using JMX to Manage Coherence in Managing Oracle Coherence.

Understanding Session Invalidation Exceptions for the Session Reaper

Each Coherence*Web instance has a session reaper that periodically iterates through all of the sessions in the session cache and checks for expired sessions. If multiple Web applications are using a Coherence*Web instance, then a reaper from one Web application can invalidate sessions used in a different application.

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