More information from the heap dump Dominator tree: org.apache.jackrabbit.oak.jcr.session.SessionStats 1,209,422 objects, used heap: 58,052,255 retained heap: 2,906,002,584
This seems like a likely culprit. Is this an indication that I am not closing sessions as thoroughly as I thought, or is SessionStats held by some other object? Jim Tully On 10/16/15, 9:12 PM, "Jim.Tully" <[email protected]> wrote: >Torgeir, > >No, the webapp runs constantly, until we finally run out of memory and are >forced to restart. We¹re currently running version 1.2.2, if that >matters. > > >Jim Tully > > >On 10/16/15, 9:07 PM, "Torgeir Veimo" <[email protected]> wrote: > >>Does your webapp restart during this time? >> >>On 17 October 2015 at 03:14, Jim.Tully <[email protected]> wrote: >>> This is probably something that we are doing incorrectly, but it has me >>>scratching my head. >>> >>> We are running Oak embedded in a web application. We construct a >>>repository at startup using fairly standard construction: >>> >>> >>> DocumentNodeStore ns= new >>>DocumentMK.Builder().setMongoDB(createMongoDB()).getNodeStore(); >>> >>> >>> Oak oak = new Oak(ns); >>> >>> >>> LuceneIndexProvider provider = new LuceneIndexProvider(); >>> >>> Jcr jcr = new Jcr(oak).with((QueryIndexProvider) >>>provider).with((Observer) provider) >>> >>> .with(new LuceneIndexEditorProvider()).withAsyncIndexing(); >>> >>> repository = jcr.createRepository(); >>> >>> Looking at the JVM memory using JVisualVM, we see that memory usage >>>increases over time. Using heap dumps, we've determined that oak object >>>is constantly growing in terms of memory footprint. >>> >>> Obviously the object will never be garbage collected, but I'm trying to >>>track down why it is growing over time. Our interactions with Oak all >>>follow the same pattern: >>> Session session = repository.login(credentials, null); >>> ... do some work >>> session.logout(); >>> >>> Any thoughts on possible reasons for Oak to keep increasing in size? >>> >>> Thanks, >>> >>> Jim >> >> >> >>-- >>-Tor >
