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