Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.2 final
    • Fix Version/s: 2.0.4, 2.1-RC2
    • Component/s: Project infrastructure
    • Labels:
      None
    • Environment:
      Win32, Tomcat 6.0.20 / 6.0.24

      Description

      When deploying a minimal Grails application to Tomcat 6.0.20 on Windows, everything works fine. When the same application is undeployed, the following libraries are locked and cannot be removed by Tomcat.

      • ehcache-core-1.7.1.jar
      • groovy-all-1.6.7.jar
      • grails-core-1.2.0.jar

      The same problem also happens if the application is configured to use the MSSQL JDBC 2.0 driver. The first time the application is deployed the database connections work fine, when the application is undeployed it does not remove the driver's JAR file and also subsequent deployments fail with JDBC connection issues.

      When deploying the exact same application on Tomcat 6.0.24 on Windows, none of the problems mentioned above occur. However the Tomcat log contains a bunch of errors like the following...

      SEVERE: A web application created a ThreadLocal with key of type [org.codehaus.groovy.runtime.GroovyCategorySupport.MyThreadLocal] (value [org.codehaus.groovy.runtime.GroovyCategorySupport$MyThreadLocal@d32ea0]) and a value of type [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@9a288b]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed.

      The full log file is attached to this issue as well as the sample grails application which triggers these errors.

      The purpose of the issue would be to fix the locking issues under Tomcat 6.0.20 and to clean up the SEVERE messages in the log file under Tomcat 6.0.24.

      Please let me know if you require any additional information. Thanks!

      1. abstract-save-persistent-leak.patch
        2 kB
        R
      2. catalina.2010-01-29.log
        13 kB
        Daniel Mikusa
      3. grails121.log
        16 kB
        Daniel Mikusa
      4. hibernate-persistence-context-leak.patch
        2 kB
        R

        Activity

        Hide
        R added a comment - - edited

        Here is a simple (untested) patch for the issue with the AbstractSavePersistentMethod noted in the next-to-previous comment. The problem is that an (anonymous) subclass of ThreadLocal is being created, and that therefore keeps a reference to the classloader. By replacing the initialValue() method with a "manual" setting of the initial value we avoid that subclass and hence the issue. As I said, though, this is untested.

        Btw., the shutdown handler here is mostly useless: it only removes the thread-local entry for the thread that happens to run the shutdown handler, but does nothing for all others. I think it could just as well be removed.

        Show
        R added a comment - - edited Here is a simple (untested) patch for the issue with the AbstractSavePersistentMethod noted in the next-to-previous comment. The problem is that an (anonymous) subclass of ThreadLocal is being created, and that therefore keeps a reference to the classloader. By replacing the initialValue() method with a "manual" setting of the initial value we avoid that subclass and hence the issue. As I said, though, this is untested. Btw., the shutdown handler here is mostly useless: it only removes the thread-local entry for the thread that happens to run the shutdown handler, but does nothing for all others. I think it could just as well be removed.
        Hide
        R added a comment -

        I have actually tested the patch now in tomcat 7.0.27 and it works. In the course of testing I also noticed that tomcat was complaining about another place where thread-locals were causing a leak:

        org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
        SEVERE: The web application [/site-0.1] created a ThreadLocal with key of type [org.codehaus.groovy.grails.orm.hibernate.support.HibernatePersistenceContextInterceptor$2] (value [org.codehaus.groovy.grails.orm.hibernate.support.HibernatePersistenceContextInterceptor$2@57f16388]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
        org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
        SEVERE: The web application [/site-0.1] created a ThreadLocal with key of type [org.codehaus.groovy.grails.orm.hibernate.support.HibernatePersistenceContextInterceptor$3] (value [org.codehaus.groovy.grails.orm.hibernate.support.HibernatePersistenceContextInterceptor$3@28bda2d3]) and a value of type [java.lang.Integer] (value [0]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
        

        I have attached a second patch for this one (same problem, same solution - and previous comment about shutdown hook basically being useless applies here too).

        Show
        R added a comment - I have actually tested the patch now in tomcat 7.0.27 and it works. In the course of testing I also noticed that tomcat was complaining about another place where thread-locals were causing a leak: org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks SEVERE: The web application [/site-0.1] created a ThreadLocal with key of type [org.codehaus.groovy.grails.orm.hibernate.support.HibernatePersistenceContextInterceptor$2] (value [org.codehaus.groovy.grails.orm.hibernate.support.HibernatePersistenceContextInterceptor$2@57f16388]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks SEVERE: The web application [/site-0.1] created a ThreadLocal with key of type [org.codehaus.groovy.grails.orm.hibernate.support.HibernatePersistenceContextInterceptor$3] (value [org.codehaus.groovy.grails.orm.hibernate.support.HibernatePersistenceContextInterceptor$3@28bda2d3]) and a value of type [java.lang.Integer] (value [0]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. I have attached a second patch for this one (same problem, same solution - and previous comment about shutdown hook basically being useless applies here too).
        Hide
        Graeme Rocher added a comment -

        I've applied to the patches, if problems persist please re-open

        Show
        Graeme Rocher added a comment - I've applied to the patches, if problems persist please re-open
        Hide
        Raphael Miranda added a comment -

        I've tested with master latest and I got:

        SEVERE: The web application [/leakapp] appears to have started a thread named [Timer-1] but has failed to stop it. This is very likely to create a memory leak.

        I created a virtual testing environment and sample app: https://github.com/xymor/grails-5823-test

        Show
        Raphael Miranda added a comment - I've tested with master latest and I got: SEVERE: The web application [/leakapp] appears to have started a thread named [Timer-1] but has failed to stop it. This is very likely to create a memory leak. I created a virtual testing environment and sample app: https://github.com/xymor/grails-5823-test
        Hide
        R added a comment -

        I noticed that too, but only when using H2 as the database, not when using PostgreSQL (i.e. only in dev/testing, not production). Don't know who the actual culprit is, though.

        Show
        R added a comment - I noticed that too, but only when using H2 as the database, not when using PostgreSQL (i.e. only in dev/testing, not production). Don't know who the actual culprit is, though.

          People

          • Assignee:
            Graeme Rocher
            Reporter:
            Daniel Mikusa
          • Votes:
            28 Vote for this issue
            Watchers:
            24 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Last Reviewed:

              Development