[jira] Issue Comment Edited: (JCR-1668) After RepositoryImpl instance has been created and shut down, some classes cannot be unloaded

["Martijn Hendriks (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JCR-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731907#action_12731907 ] 

Martijn Hendriks edited comment on JCR-1668 at 7/16/09 7:08 AM:
----------------------------------------------------------------

There's yet another background thread that gives a memory leak in environments where the jackrabbit libraries can be dynamically updated (OSGi, webapps, ...): the revision table janitor in the DatabaseJournal class. This thread must be stopped when the "stop" method of the journal is called.

W.r.t. the TransientFileFactory: can't we automate the call to shutdown? If RepositoryImpl.create registers the just created instance at the TransientFileFactory and RepositoryImpl.doShutdown de-registers the current instance, then TransientFileFactory can keep a reference count and call shutDown itself when the reference count is 0. Mmm...that will not work if the TransientFileFactory is used outside the scope of an active repository instance and that could very well be the case judging from the classes that use it...

      was (Author: martijnh):
    There's yet another background thread that gives a memory leak in environments where the jackrabbit libraries can be dynamically updated (OSGi, webapps, ...): the revision table janitor in the DatabaseJournal class. This thread must be stopped when the "stop" method of the journal is called.

W.r.t. the TransientFileFactory: can't we automate the call to shutdown? If RepositoryImpl.create registers the just created instance at the TransientFileFactory and RepositoryImpl.doShutdown de-registers the current instance, then TransientFileFactory can keep a reference count and call shutDown itself when the reference count is 0.
  
> After RepositoryImpl instance has been created and shut down, some classes cannot be unloaded
> ---------------------------------------------------------------------------------------------
>
>                 Key: JCR-1668
>                 URL: https://issues.apache.org/jira/browse/JCR-1668
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core, jackrabbit-jcr-commons
>    Affects Versions: 1.4, commons 1.4.2, core 1.4.5
>         Environment: windows vista
> java version "1.6.0_06"
> Jetty 6.1.9
> Apache Tomcat 6.0.14
>            Reporter: Roman Puchkovskiy
>         Attachments: JCR-1636-reaper-thread.patch, test-undeploy-v2.zip
>
>
> I've built a simple web-application, which contains one servlet loaded at start-up. In its init() method an instance of RepositoryImpl() is created, in its destroy() method this instance is stopped (using shutdown()).
> From the servlet code, only classes in jackrabbit-core, JCR API and Servlet API are referenced.
> jackrabbit-core version is 1.4.5, and jackrabbit-jcr-commons version is 1.4.2. Other jackrabbit libs are all of 1.4 version.
> Even if servlet's doGet() method never gets called, when the web-application is redeployed, all its classes still hang in memory, which produces a memory leak.
> init() method is 
>     public void init() throws ServletException {
>         super.init();
>         try {
>             RepositoryConfig repoConfig = RepositoryConfig.create(getClass().getResourceAsStream("repository.xml"), ".");
>             repo = RepositoryImpl.create(repoConfig);
>         } catch (Exception e) {
>             throw new ServletException(e);
>         }
>     }
> while destroy() method is
>     public void destroy() {
>         repo.shutdown();
>         super.destroy();
>     }
> Even when I applied patches from JCR-1636 and added TransientFileFactory.shutdown() call to destroy() method, nothing has changed.
> Tested this in Jetty 6.1.9 and Tomcat 6.0.14.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.