inactive-timeout/timeout delay in webseald.conf will have some delay before taking effect

Cause

The session timeout mechanism is a separate thread that checks for inactivity and total durations against every session in WebSEAL's cache.

Because the operations involved are relatively expensive and WebSEAL may have many sessions to check, the session timeout thread does not make continuous, or even frequent checks against the session cache.

The thread sleeps for 1/4 of either inactive-timeout or timeout, whichever is shorter. When its done sleeping, it runs through every session to flag the expired ones, then goes back to sleep.

So if a user begins his session shortly after a period during which the session timeout thread made its last check, his session will not timeout until after the next four checks are made. It appears inconsistent because testers have no way of knowing where in the session timeout thread's sleep/check cycle they have initiated their session lifetime. Furthermore, they don't know how long it has been since the session has actually expired.

          inactive
    |<-----timeout----->|
____|____|____|____|____|____|
 ^a ^b                  ^c


A monospace font will display the above diagram correctly.
1) A session is initiated, and further activity ceases.
2) The session timeout thread notes the beginning of the session's inactivity.
3) The fourth timeout check after inactivity began arrives, and the timeout
   thread flags the session. A grace period preserves the session temporarily,
   should the user re-authenticate.
4) The user makes another request and discovers his session has expired.

The letters a, b, and c signify points on a timeline. Each vertical bar represents the point where the thread checks for inactive-timeout. You will observe c - a can be significantly larger than c - b, the inactive-timeout.

-----------------------------------------------------------------------------