https://bz.apache.org/bugzilla/show_bug.cgi?id=68558
--- Comment #2 from John Engebretson <jeng...@amazon.com> ---
> Are you sure about the request parameters being parsed multiple times? They
> should only be parsed once per request.
Yes - this appears to be triggered when an extra param is added by a JSP
include, for example:
<jsp:include page="/myExample.jsp" >
<jsp:param name="type" value="image" />
<jsp:param name="index" value="${status.index}" />
</jsp:include>
ApplicationDispatcher.wrapRequest is invoked and creates a new
ApplicationHttpRequest with un-parsed parameters. If the included JSP ever
checks the parameters, the full set of parameters is parsed: the original plus
any new ones added by the <jsp:include>. Nested JSP includes can trigger
reparsing once per nest.
Relevant stack trace:
org.apache.catalina.core.ApplicationDispatcher.org.apache.catalina.core.ApplicationDispatcher.doInclude
org.apache.catalina.core.ApplicationDispatcher.doInclude
org.apache.catalina.core.ApplicationDispatcher.include
org.apache.jasper.runtime.JspRuntimeLibrary.include
> Is org.apache.tomcat.util.buf.StringCache not caching the Strings or is just
> that local caching has much lower latency (which wouldn't surprise me)?
Lower latency. 70% of StringCache.toString() is spent in
org.apache.tomcat.util.buf.StringCache.findClosest() which does appear to
function as intended.
> Caching the String in ByteChunk.toString() is an option. I did look at that
> when I last worked on this code but it raises all sorts of complications
> around cache invalidation as the byte array is directly accessible.
Makes sense. :( This may be easier for org.apache.coyote.Request, where a
reference to MessageBytes could be replaced by a reference to String (possibly
lazy-loaded).
--
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
