Details
Open
Critical
Description
Any Groovy application (including Grails apps) that deploy to Tomcat 6.0.26 and above has this issue because basically Tomcat clears thread locals not manually shutdown by the application to prevent memory leaks.
This can lead to problems starting and stopping Groovy based application with errors like the following occuring:
[java] Exception in thread "Thread-3" java.lang.NullPointerException
[java] at org.codehaus.groovy.runtime.GroovyCategorySupport.hasCategoryInCurrentThread(GroovyCategorySupport.java:216)
[java] at groovy.lang.MetaClassImpl.getMethodWithCaching(MetaClassImpl.java:1128)
[java] at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:904)
[java] at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:915)
[java] at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:886)
[java] at groovy.lang.Closure.call(Closure.java:276)
[java] at groovy.lang.Closure.call(Closure.java:271)
[java] at groovy.lang.Closure.run(Closure.java:354)
Groovy needs to include the ability to manually shutdown the any categories that exist in any threads and also re-instate the categories if they are nulled (like what happens with Tomcat)
Issue Links
- relates to
-
GROOVY-4698
Possible memory leak in Tomcat
-
This looks very much like the threadInfo filed in GroovyCategorySupport got nulled. We use TheadLocals at several places. From your description I see that all of them would be having that problem. The problem is, that the threadInfo is a final static variable and is so for a good reason. The any way to "fix" this inside Groovy will cost performance. I would for example have to synchronize access to this field. Is there no way to prevent tomcat from cleaning ThreadLocals used by the Groovy runtime?