You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Bob Damato <bo...@coxtarget.com> on 2006/06/13 16:49:45 UTC

What triggers jspDestroy?

Hello, I got no response for this on the tomcat-users list. I think it may be more appropriate for this list since it's more about the internals of Tomcat:

--------------------------------------

I have a page that renders a very large report using the apache jstl
tags. When the page has finished running, my memory usage jumps up 70MB.
Even if I force a full garbage collection (verified in my garbage
collector log), memory usage does not decrease. There is no data being
cached or stored in the user's session, it's simply dumped into the
request and rendered by the JSP. I've found that if I un-deploy the war
and force a full garbage collection, memory usage drops 70MB. I've also
found that after waiting about 30 minutes, the memory is released.

When I did memory snapshots before and after running that page, I could
still see the page exists in memory (org.apache.jsp.ContactReport_jsp)
and appears to be holding on to that 70MB. From what I've read
(http://issues.apache.org/bugzilla/show_bug.cgi?id=25623) , it's seems
like the memory that is used by the jstl foreach tag is not released
until the page is destroyed. I'd like to verify this is truly the case
and I'd also like to find out exactly what triggers the call to
jspDestroy. Is there a timer, a thread, a memory threshold? Is there
something I can/should configure to keep the page from eating up all of
that memory for so long? I've tried disabling tag pooling, but that had
no effect.

Thanks!!

Re: What triggers jspDestroy?

Posted by Jan Luehe <Ja...@Sun.COM>.
Hi Bob,

Bob Damato wrote On 06/13/06 07:49,:

>Hello, I got no response for this on the tomcat-users list. I think it may be more appropriate for this list since it's more about the internals of Tomcat:
>
>--------------------------------------
>
>I have a page that renders a very large report using the apache jstl
>tags. When the page has finished running, my memory usage jumps up 70MB.
>Even if I force a full garbage collection (verified in my garbage
>collector log), memory usage does not decrease. There is no data being
>cached or stored in the user's session, it's simply dumped into the
>request and rendered by the JSP. I've found that if I un-deploy the war
>and force a full garbage collection, memory usage drops 70MB. I've also
>found that after waiting about 30 minutes, the memory is released.
>
>When I did memory snapshots before and after running that page, I could
>still see the page exists in memory (org.apache.jsp.ContactReport_jsp)
>and appears to be holding on to that 70MB. From what I've read
>(http://issues.apache.org/bugzilla/show_bug.cgi?id=25623) , it's seems
>like the memory that is used by the jstl foreach tag is not released
>until the page is destroyed. I'd like to verify this is truly the case
>and I'd also like to find out exactly what triggers the call to
>jspDestroy. Is there a timer, a thread, a memory threshold? Is there
>something I can/should configure to keep the page from eating up all of
>that memory for so long? I've tried disabling tag pooling, but that had
>no effect.
>  
>

jspDestroy() is called when the container invokes the
destroy() method of the servlet into which your JSP page
was compiled, which will happen when the webapp containing
your JSP is undeployed.

Are you overriding jspDestroy() in your page?

Notice that jspDestroy() is different from Tag.release(),
which is invoked on a tag handler once all invocations
on the tag handler are completed. If pooling is disabled,
a tag handler's release() method will be called right
after the tag handler's doEndTag() method, but when
pooling is enabled, each pooled tag handler's release()
method will be invoked as part of the servlet's destroy().


Jan


>Thanks!!
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org