Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-11759

Memory leak affecting policy evaluation for stateless sessions

    Details

    • Needs backport:
      Yes
    • Support Ticket IDs:
    • Needs QA verification:
      No
    • Functional tests:
      No
    • Are the reproduction steps defined?:
      No (add reasons in the comment)

      Description

      Bug description

      When running the PushZ performance test using stateless sessions we see GC thrashing and poor performance. This is at least in part due to a memory leak in com.sun.identity.policy.SubjectEvaluationCache; this cache keeps a record of which subject IDs a given session does and does not match. It is keyed on token ID (which for stateless sessions can be quite large) and is cleared when the relevant session is destroyed. Unfortunately, when using stateless sessions, there is never any notification for sessions timeouts and therefore the cache is not emptied.

      How to reproduce the issue

      Run the PushZ performance test with stateless sessions for an extended period and watch the memory usage grow.

      Expected behaviour
      OpenAM caches should not depend on notification of stateless session timeouts in order to clear their contents. Instead, caches should be bounded and apply an LRU policy. Additionally, entries may be automatically removed after a "timeout" based on when the entry was added or last updated.
      
      Current behaviour
      Cache is unbounded and does not clear entries relating to dead sessions.
      

      Work around

      This cache can be disabled:

      • Select Configure > Global Services > Policy
      • Select the Realm Defaults tab
      • Set "Subjects Result Time to Live" to 0
      • Select "Save Changes"

      Code analysis

      com.sun.identity.policy.SubjectEvaluationCache#subjectEvaluationCache should be a Guava Cache rather than a HashMap.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                craig.mcdonnell Craig McDonnell
                Reporter:
                craig.mcdonnell Craig McDonnell
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: