DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44389>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44389

           Summary: Cleanup of org.apache.naming.resources.CacheEntry
                    resources (memory leak)
           Product: Tomcat 6
           Version: 6.0.14
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


Hi,

   I am memory profiling a webapp for my company because we suspect it has
memory leaks when redeploying. This webapp has to be redeployed several times a
week for security reasons (most of the time it is undeployed) and the memory
leaks forced us to shutdown tomcat once a week to avoid OOM exception.

   I'm using jvm1.5 and tomcat 6.0.13 (also tried with 6.0.14 and today with
6.0.16), and Yourkit as the profiling tool. I have made the test in both linux
and windows.

   I have created a JMeter test to deploy the app using the manager, make some
request to the app and then undeploy it using again the manager app in a loop.
After some redeployments, I got my OutOfMemoryException. Then I checked with my
profiling tool and found that my own classes were correctly destroyed, and the
classes retaining more memory were these ones (listed as a heirarchy):

   org.apache.catalina.core.ApplicationContext$DispatchData
   org.apache.catalina.core.ApplicationContext
mapper of  org.apache.catalina.core.StandardContext
context of  org.apache.tomcat.util.http.mapper.Mapper
resources of  org.apache.tomcat.util.http.mapper.Mapper$Context  cache of 
org.apache.naming.resources.ProxyDirContext  cache of 
org.apache.naming.resources.ResourceCache
org.apache.naming.resources.CacheEntry[]

   The number of objects of each class were exactly the number of times I had
redeployed the webapp. I have checked the contents of CacheEntry inside
CacheEntry[] and it has an attribute "name" and the contents are the jsps and
tld files of my app. There are as many CacheEntry with the same jsp attribute as
times the webapp has been reloaded, so I guess there is no cleaning of
CacheEntry resources at context shutdown.

   To reproduce this, a simple webapp with 2 jsp and a taglibrary can be used.
Deploy and undeploy it many times so you can see how the count of these objects
grows in memory.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to