4 Replies Latest reply on Dec 4, 2017 11:55 PM by sivaa

    Memory footprint of long-running session

    zcc39r

      Considering Short-lived vs long-lived sessions and ModeShape memory usage it's become inevitable to avoid long-running sessions. But using observation feature of JCR seems impossible without long-running session. And I have a memory exhausting problem with this observation session. Initially there is only one observation session exists. Then, after filling in the repository with 200000-300000 nodes via short-lived sessions, I can see (with help of jvisualvm) that only one (observation) instance of JcrSession remains and a pair of gigabytes of memory can't be released by GC till the close of this session. But closing of this observation session is undesirable - observation should be continuous. There are no repository nodes being accessed via observation session - the onEvent() method of my EventListener implementation works only with Event objects.

       

      So my question is how to reduce the memory footprint of this observation session? May be via some repository configuration parameters? Or may be this is a bug.

        • 1. Re: Memory footprint of long-running session
          hchiorean

          If this long lived session never loaded / had anything to do with the nodes created by the other sessions, it shouldn't be keeping any references (i.e. acting as a GC root). Only after a session accesses a node will that node (and whatever lies beneath) become strongly referenced by that session.

           

          So it would help if you investigate the GC roots in your case and check where the unclean references come from. In general, once a short lived session is logged out (session.logout) it is removed from the repository Map which holds active sessions and therefore it should become eligible for GC.

          • 2. Re: Memory footprint of long-running session
            zcc39r

            become strongly referenced by that session

            Does it mean that weak references can exist too?

             

            Most memory hungry objects of ModeShape I can see are instances of org.modeshape.schematic.internal.document.BasicDocument. And GC root as far as I understand is observation session. After closing this session and performing GC the number of the objects mentioned above reduces dramatically. Will it be helpful if I provide you with the heap dump?

            • 3. Re: Memory footprint of long-running session
              hchiorean

              Does it mean that weak references can exist too?

              There are a variety of inter-object references which are stored by ModeShape, both weak and strong. From a GC perspective, only the strong ones are relevant. From the perspective of a potential memory leak, it's important that once a session is logged out all referenced objects together with that session can be GCed.

               

              Are you using by any change a custom workspaceCache size ? (default is 10k). The workspace cache is the other place which stores in-memory data shared by sessions and which is not cleared unless a WS is deleted or the repository shut down.

               

              Feel free to attach the heap dump and once I get the chance, I'll look at it.

              • 4. Re: Memory footprint of long-running session
                sivaa

                If the default workspaceCache is 10k , does it mean  Modeshape still holds these in-memory references object shared shared by the sessions. Is it a memory leak inside Modeshape?