Tomcat not invalidating sessions

To configure the reaper to invalidate sessions serially, set the .

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.

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.

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.

During the reaping cycle, the Session Reaper scans for expired sessions.

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.

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.

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.

Every application server running Coherence*Web runs the Session Reaper.