https://issues.apache.org/bugzilla/show_bug.cgi?id=46397
Summary: Potential memory leak with TagHandlers and JspIdConsumer Product: Tomcat 6 Version: unspecified Platform: Macintosh OS/Version: Mac OS X 10.4 Status: NEW Severity: normal Priority: P2 Component: Jasper AssignedTo: dev@tomcat.apache.org ReportedBy: jochen.wut...@gmx.de Created an attachment (id=23022) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23022) test case app As a follow up on the thread on the mailing list, here's my summary again: Since the JSP Spec says that TagHandlers implementing JspIdConsumer may not be reused, I was expecting them to be collected after the servlet finishes processing. A few experiments showed that that is not the case. After delving into the details of the servlet code generated for JSP pages I discovered that the methods instantiating TagHandlers also store them in TagHandlerPools using #reuse(). I ran some more experiments to see what happens with these TagHandlers. My setup is Tomcat 6 + MyFaces + JSF CarDemo, and I'm using AspectJ to trace creation and garbage collection of objects implementing JspIdConsumer. My experiments indicate the following: 1. JspIdConsumer instances do NOT get garbage collected after a page has finished processing. 2. JspIdConsumer instances do NOT always get garbage collected after a session times out. 3. SOME JspIdConsumer instances DO get garbage collected when a given JSP-generated page is reloaded or accessed in a different session. To obtain these results I ran Tomcat with very little heap memory (it seems it starts fine with the 64M default), loaded the car demo in several browser sessions and ran through all the other JSP/Servlet examples that come with Tomcat to increase the memory consumption and trigger GC. Unfortunately I don't have the time and tools to do a proper stress test. To provide some sort of simpler test case, I attach a WAR to use, but you still need to put the runtime library of AspectJ (aspectjrt.jar) on the classpath when running Tomcat. The behavior I observe is that whenever I load/reload the page, the JspIdConsumer objects get allocated, and some, but never all of them get GC'd. You should see messages on the console/log like Adding JspIdConsumer:<someClassName>:<itsHashCode>:<theJspId> and Removed <someJspId> You will see three "Adding messages" for every instance created (it's a mess to track this properly), and you should see one "Removed" message for every GC'd instance. When I run grep | wc on the output, the "distance" between the number of created and GC'd object grows over time and reloads of the test page. I had this running for a bit, trying to see if after a session timeout the remaining instances would be GC'd, but they didn't. I don't know what to make of this, but it feels like Tomcat is holding on to some of the instances for too long for no good reason. In any case, considering the specification of JspIdConsumer, which states that instances may never be reused, the caching of these instances as it is done in current JSPs is unnecessary, and since these instances don't seem to be GC'd, this seems to be a memory leak. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org