Uploaded image for project: '[Read Only] - Hippo Site Toolkit 2'
  1. [Read Only] - Hippo Site Toolkit 2
  2. HSTTWO-2847

Usage of WeakReference<Session> in LazySessionInvoker leads to memory leak



    • Bug
    • Status: Closed
    • Normal
    • Resolution: Fixed
    • None
    • 2.26.11, 2.28.00
    • None
    • None


      The analysis of HIPCON-1070 showed a memory leak regarding JCR sessions that never got logged out, accumulating until there was no more memory left. The analysis showed that the sessions were all logged in siteusers. After enabling logging on production we saw that the valueUnbound method of the LazySession proxies got called, while often the underlying JCR session that is referenced via a WeakReference had disappeared.

      I managed to reproduce this locally quite easily.

      • Use connect trunk
      • Set org.hippoecm.hst.core.jcr.LazySessionDelegatingRepository logger to debug in conf/log4j-dev.xml.
      • set session timeout to 1 minute in site's web.xml
      • log in a couple of times with user admin using different sessions

      After a minute of inactivity you will start seeing debug messages:
      "LazySession session value is being unbound."
      These message should be followed by:
      "LazySession's session is logged out."

      This latter message often does not happen because the underlying session has disappeared.

      If you now attach a profiler and make a memory dump, you will notice the sessions that could not be logged out are still strongly reachable..

      Perhaps there is a bug in the JVM dereferencing logic in combination with dynamic proxies? Or else there is might be a race condition between garbage collection and registering the session elsewhere under a hard reference.

      Anyway, we couldn't understand what was the reason for using a WeakReference inside the LazySessionInvoker. And getting rid of the WeakReference there fixes the issue.


        Issue Links



              jsheriff Junaidh Kadhar Sheriff
              uhommes Unico Hommes (Inactive)
              0 Vote for this issue
              3 Start watching this issue