[jira] [Commented] (TILES-522) Performance of TemplateAttributeRender in Tomcat

["Mck SembWever (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TILES-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053382#comment-13053382 ] 

Mck SembWever commented on TILES-522:
-------------------------------------

Trying a similar approach in Tiles-3 did not work, eg in JspRequest
{noformat}    protected void doInclude(String path) throws IOException {
        try {
            pageContext
                    .getServletContext()
                    .getRequestDispatcher(path) 
                    .include(pageContext.getRequest(), pageContext.getResponse()); 
        } catch (ServletException e) {
            throw ServletUtil.wrapServletException(e, "JSPException including path '"
                    + path + "'.");
        }
    }{noformat}
Everything written to the JspRequest stream came out but that written to the ServletRequest's stream (the template) didn't. 

> 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
>         Attachments: TILES-522.patch
>
>
> 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