Bug 50661 - c:forEach tag doesn't release his list - it causes temporary memory leak
Summary: c:forEach tag doesn't release his list - it causes temporary memory leak
Status: RESOLVED DUPLICATE of bug 25623
Alias: None
Product: Taglibs
Classification: Unclassified
Component: Standard Taglib (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-26 11:26 UTC by Sergiusz
Modified: 2011-01-27 02:57 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergiusz 2011-01-26 11:26:19 UTC
Sorry for my English.

In <c:forEach> implementation, there are two internal variables: rawItems and items. They hold a list, which is iterated with <c:forEach> statement. The problem is, that after the iteration has finished, the variables still hold the list! It would not be a problem if the Tag would be released after request ends. But IT IS a problem because the Tag (according to JSP specification) remains in memory and can be reused later by another request.

So, it is possible, that the list which is held by rawItems, remains in memory many hours until another request releases it. If there ist a VERY BIG LIST with VERY BIG OBJECTS, it could be a VERY BIG PROBLEM with memory on JVM. And it was - on my server.

I did a workaround of this. I made a class which extendeds ForEachTag and I wrote such method:

@Override
public int doEndTag() throws JspException
{
	int wynik = super.doEndTag();
	this.rawItems = null ;
	this.items = null ;
	return wynik ;
}

Now I use my own forEach tag.

I think, such "memory optimalization" should be made in a standard implementation.

Sergiusz
Comment 1 Jeremy Boynes 2011-01-27 02:57:56 UTC
As discussed in the related issue, the items cannot be released in doEndTag() as the tag is required by the spec to retain its attribute values until release() is called.

*** This bug has been marked as a duplicate of bug 25623 ***