[
https://issues.apache.org/jira/browse/TILES-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mck SembWever updated TILES-522:
--------------------------------
Description:
TeamplateAttributeRender.write(..) boils down to using
JspRuntimeLibrary.include(..)
In Tomcat-6 this involves wrapping the request and response (a number of
times?) and going through security checks (again and again and again...).
At FINN.no we're getting scores of requests per second per jvm and seeing this
method becoming a bottleneck, mainly due to thread contention in the security
checks.
The method can be sped up by calling, if possible, requestDispatcher.include(..)
For example we have overridden TemplateAttributeRender like
public void write(
final Object template,
final Attribute attribute,
final TilesRequestContext request) throws IOException {
if(request instanceof JspTilesRequestContext && template instanceof
String){
try {
((JspTilesRequestContext) request)
.getPageContext()
.getServletContext()
.getRequestDispatcher((String)template)
.include((ServletRequest) request.getRequest(),
(ServletResponse) request.getResponse());
} catch (ServletException ex) {
throw new TilesIOException(ex);
}
}else{
super.write(template, attribute, request);
}
}
I doubt that this is an appropriate patch to apply, it hides superclass
functionality, but maybe there is a better place to apply it?
was:
TeamplateAttributeRender.write(..) boils down to using
JspRuntimeLibrary.include(..)
In Tomcat-6 this involves wrapping the request and response (a number of
times?) and going through security checks (again and again and again...).
At FINN.no, norway's second largest website, we're getting scores of requests
per second per jvm and seeing this method becoming a bottleneck, mainly due to
thread contention in the security checks.
The method can be sped up by calling, if possible, requestDispatcher.include(..)
For example we have overridden TemplateAttributeRender like
public void write(
final Object template,
final Attribute attribute,
final TilesRequestContext request) throws IOException {
if(request instanceof JspTilesRequestContext && template instanceof
String){
try {
((JspTilesRequestContext) request)
.getPageContext()
.getServletContext()
.getRequestDispatcher((String)template)
.include((ServletRequest) request.getRequest(),
(ServletResponse) request.getResponse());
} catch (ServletException ex) {
throw new TilesIOException(ex);
}
}else{
super.write(template, attribute, request);
}
}
I doubt that this is an appropriate patch to apply, it hides superclass
functionality, but maybe there is a better place to apply it?
> Performance of TemplateAttributeRender in Tomcat
> ------------------------------------------------
>
> Key: TILES-522
> URL: https://issues.apache.org/jira/browse/TILES-522
> Project: Tiles
> Issue Type: Task
> Components: tiles-core
> Affects Versions: 2.2.2
> Environment: Java6, Java7, Tomcat6
> Reporter: Mck SembWever
> Priority: Minor
> Labels: performance
>
> TeamplateAttributeRender.write(..) boils down to using
> JspRuntimeLibrary.include(..)
> In Tomcat-6 this involves wrapping the request and response (a number of
> times?) and going through security checks (again and again and again...).
> At FINN.no we're getting scores of requests per second per jvm and seeing
> this method becoming a bottleneck, mainly due to thread contention in the
> security checks.
> The method can be sped up by calling, if possible,
> requestDispatcher.include(..)
> For example we have overridden TemplateAttributeRender like
> public void write(
> final Object template,
> final Attribute attribute,
> final TilesRequestContext request) throws IOException {
> if(request instanceof JspTilesRequestContext && template instanceof
> String){
> try {
> ((JspTilesRequestContext) request)
> .getPageContext()
> .getServletContext()
> .getRequestDispatcher((String)template)
> .include((ServletRequest) request.getRequest(),
> (ServletResponse) request.getResponse());
> } catch (ServletException ex) {
> throw new TilesIOException(ex);
> }
> }else{
> super.write(template, attribute, request);
> }
> }
> I doubt that this is an appropriate patch to apply, it hides superclass
> functionality, but maybe there is a better place to apply it?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
