jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryl Beattie" <dar...@date.com>
Subject RE: Memory Leak in ELEvaluator (cont'd...)
Date Wed, 23 Feb 2005 16:50:45 GMT
Please see below:

> -----Original Message-----
> From: Felipe Leme [mailto:jakartalists1@felipeal.net] 
> Sent: Sunday, February 20, 2005 8:14 PM
> To: Tag Libraries Developers List
> Subject: RE: Memory Leak in ELEvaluator (cont'd...)
> 
> 
> On Fri, 2005-02-18 at 19:35, Daryl Beattie wrote:
> > 	It is not used anymore? I thought the JSTL expression 
> language and 
> > the JSP expression language were two different languages;
> 
> They're basically the same, except by a few differences (for 
> instance, JSP 2.0's EL has functions; JSTL 1.0's doesn't).

	Okay, that's cool.

> > if so, how could the JSTL delegate evaluation to the JSP?
> 
> On JSP 2.0, the EL is evaluated by the JSP container, not the 
> tag handlers. So, if the error still exists on JSTL 1.1, it 
> should be fixed on the web server (for instance, on Jakarta 
> Commons EL in the case of Tomcat-based servers).

	Understood. So I don't suppose anybody knows of such a problem
with Tomcat or Jetty?

> > 	No, I have not tried with JSTL 1.1; we are still using 
> my hacked 
> > version of 1.0.6. Is a migration to 1.1 a big change? Where 
> can I get 
> > a changelog for the JSTL to help in my estimation of how much work 
> > this would be?
> 
> There are 2 majors changes you need to do in order to migrate:
> - use a JSP 2.0 compatible web container (like Tomcat 5.x)
> - change the URL for the taglibs (for instance, 
> http://java.sun.com/jsp/jstl/core instead of
http://java.sun.com/jstl/core).

	That doesn't sound too bad, though it might require an upgrade
of the servlet container (currently Jetty 4.19). I would have to upgrade
to Jetty 5.0+ to solve the problem -- and even then there's no telling
how Jetty handles the expression evaluation.
	I will look into this and get back to you...

> > like this; <c:if test="${whatever}">...</c:if>. The specific test I

> > used to measure the leak was with our proprietary code that I cannot

> > provide to people outside the company I work for (sorry...). I can 
> > retest any
> 
> What about creating a similar test case, with generic code (not
proprietary to your company)?

	I could, yes.... Though it would simply be something like:

test.jsp:
<%@taglib uri="http://java.sun.com/jstl/core" prefix="c"%>
<html>
<head>
	<meta http-equiv="refresh" content="0;
URL=/test.jsp?rand=<%=java.lang.Math.random()%>">
</head>
<body>
	<c:if test="${!empty param.rand}">random: <c:out
value="${param.rand}"/></c:if>
	<c:if test="${empty param.rand}">random: NONE</c:if>
</body>
</html>

	--I actually compiled this JSP and tested it by deploying to my
root context. It does what is expected; evaluates 3 random expressions
each time it loads. With the expressions being cached and never expired
from that cache under JSTL 1.0, this should indicate a leak just by
watching the size of the cache grow indefinitely.
	I have code in my admin-tool that graphs the size of the
expression evaluation cache, so I can provide graphical test results for
any fixed that are provided. However, I suggest using a profiler to get
results.
	Thanks again for your help.

Sincerely,

	Daryl.


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


Mime
View raw message