You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Chetan Mehrotra (JIRA)" <ji...@apache.org> on 2015/04/09 17:04:12 UTC

[jira] [Resolved] (OAK-2741) oak shutdown, unstopped threads

     [ https://issues.apache.org/jira/browse/OAK-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chetan Mehrotra resolved OAK-2741.
----------------------------------
    Resolution: Duplicate

[~iampivot] I already created OAK-2736 for that so resolving this as duplicate


> oak shutdown, unstopped threads
> -------------------------------
>
>                 Key: OAK-2741
>                 URL: https://issues.apache.org/jira/browse/OAK-2741
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>         Environment: tomcat 7.0.59, 8.0.21, OSX, 
>            Reporter: Torgeir Veimo
>
> 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();
> Chetan Mehrotra says:
> 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.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)