jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martijn Hendriks (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (JCR-1668) After RepositoryImpl instance has been created and shut down, some classes cannot be unloaded
Date Thu, 16 Jul 2009 14:10:15 GMT

    [ 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.


Mime
View raw message