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

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
          Issue Type: Bug
          Components: jackrabbit-core, jackrabbit-jcr-commons
    Affects Versions: commons 1.4.2, 1.4, 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: test-undeploy.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.

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

Roman Puchkovskiy updated JCR-1668:
-----------------------------------

    Attachment: test-undeploy.zip

Attaching the test web-application.

> 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
>          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: test-undeploy.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.

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

Roman Puchkovskiy updated JCR-1668:
-----------------------------------

    Attachment: JCR-1636-reaper-thread.patch

Attaching a patch improving initial JCR-1636 patch. The patch stops the reaper thread too when shutting the TransientFileFactory down.
But even with this patch applied, web-application behaves the same way when redeploying: classes are not unloaded.

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

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

Roman Puchkovskiy updated JCR-1668:
-----------------------------------

    Attachment: test-undeploy-v2.zip

Attaching a second version of web-application. It unregisters database drivers and shuts log4j down on servlet destroy. Introspector caches are flushed.
But still cannot be unloaded.

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

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

Roman Puchkovskiy updated JCR-1668:
-----------------------------------

    Attachment:     (was: test-undeploy.zip)

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

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

Marcel Reutegger commented on JCR-1668:
---------------------------------------

The following worked for me:

- Deploy jackrabbit-webapp-1.5-SNAPSHOT into tomcat
- Stop tomcat
- *Move* derby-10.2.1.6.jar from WEB-INF/lib to commons/lib
- Redeploying the webapp several times will eventually unload obsolete classes

It seems there is a background thread in derby that prevents unloading of classes (AntiGC), unless you shutdown derby completely.
See: http://db.apache.org/derby/docs/10.4/devguide/tdevdvlp20349.html

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

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

Roman Puchkovskiy commented on JCR-1668:
----------------------------------------

Marcel, thanks for the link. The following line does the trick:
DriverManager.getConnection("jdbc:derby:;shutdown=true");

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