This looks like the pool of 32 threads created in Oak.defaultScheduledExecutor which is not shutdown when content repository is closed (L587 in Oak class). In many cases the executor is provided from outside so close logic needs to take care if the executor is created by itself then it should be closed also.
Can you create a issue for that? Chetan Mehrotra On Tue, Apr 7, 2015 at 6:08 PM, Torgeir Veimo <[email protected]> wrote: > I run oak in a non-osgi environment (tomcat) and am seeing these on > webapp reload; > > SEVERE: The web application [/frontend] appears to have started a > thread named [oak-scheduled-executor-274] but has failed to stop it. > This is very likely to create a memory leak. > Apr 07, 2015 2:27:20 PM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > [...] > > There's 32 of them, which roughly corresponds to the number of indexes > I've configured (27 custom indexes + 5). The repository is constructed > as > > private Repository oakRepository; > private SegmentStore segmentStore; > > segmentStore = new FileStore(new File(oakRepositoryPath), 256); > NodeStore nodeStore = new SegmentNodeStore(segmentStore); > oakRepository = new Jcr(nodeStore) > .with(new LocalInitialContent()) > .withAsyncIndexing() > .createRepository(); > > and shut down using > > ((RepositoryImpl)oakRepository).shutdown(); > segmentStore.close(); > > Is there anything else I can do to get these threads closed properly, > or is there something that needs to be addressed elsewhere? > > -- > -Tor >
