Tiles
  1. Tiles
  2. TILES-522

Performance of TemplateAttributeRender in Tomcat

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 2.2.2
    • Fix Version/s: None
    • Component/s: tiles-core
    • Labels:
    • Environment:

      Java6, Java7, Tomcat6

    • Flags:
      Patch

      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?

      1. TILES-522.patch
        0.9 kB
        Mck SembWever

        Activity

        Show
        Antonio Petrelli added a comment - You might want to modify JspTilesRequestContext: http://svn.eu.apache.org/repos/asf/tiles/framework/trunk/tiles-jsp/src/main/java/org/apache/tiles/jsp/context/JspTilesRequestContext.java
        Hide
        Mck SembWever added a comment -

        Yes of course. It is was in TemplateAttributeRender because we already had that class custom in our application.
        I will test it in JspTilesRequestContext.

        Show
        Mck SembWever added a comment - Yes of course. It is was in TemplateAttributeRender because we already had that class custom in our application. I will test it in JspTilesRequestContext.
        Hide
        Mck SembWever added a comment -

        Suggested patch to JspTilesRequestContext

        Show
        Mck SembWever added a comment - Suggested patch to JspTilesRequestContext
        Hide
        Mck SembWever added a comment - - edited

        Trying a similar approach in Tiles-3 did not work, eg in JspRequest

        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 + "'."); }

        Everything written to the JspRequest stream came out but that written to the ServletRequest's stream (the template) didn't.

        Show
        Mck SembWever added a comment - - edited Trying a similar approach in Tiles-3 did not work, eg in JspRequest 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 + "'."); } Everything written to the JspRequest stream came out but that written to the ServletRequest's stream (the template) didn't.
        Hide
        Antonio Petrelli added a comment -

        There is problem I should have noticed before.
        When you use PageContext.include you are sure you are putting stuff in JSP response stream. When you are using RequestDispatcher.include you are putting stuff in HttpResponse stream, that might be different.
        In my experience, I noticed that writing to HttpResponse when there is a JSP page, things appear before the intended places.
        Probably there is some sort of "precendence" of HttpResponse over JSP page context.

        Show
        Antonio Petrelli added a comment - There is problem I should have noticed before. When you use PageContext.include you are sure you are putting stuff in JSP response stream. When you are using RequestDispatcher.include you are putting stuff in HttpResponse stream, that might be different. In my experience, I noticed that writing to HttpResponse when there is a JSP page, things appear before the intended places. Probably there is some sort of "precendence" of HttpResponse over JSP page context.
        Hide
        Mck SembWever added a comment -

        Yes. But in this case i'm not mixing. Using the hack both ServletRequest and JspRequest are using the requestDispatcher.
        For example i even tried rewriting JspRequest.createServletJspRequest(..) to instead return a ServletRequest. Same misbehaviour occurred.
        (thinking out aloud) Can it be that there's a difference between pageContext.getResponse() and the servlet's response?

        Show
        Mck SembWever added a comment - Yes. But in this case i'm not mixing. Using the hack both ServletRequest and JspRequest are using the requestDispatcher. For example i even tried rewriting JspRequest.createServletJspRequest(..) to instead return a ServletRequest. Same misbehaviour occurred. (thinking out aloud) Can it be that there's a difference between pageContext.getResponse() and the servlet's response?
        Hide
        Antonio Petrelli added a comment -

        In fact you are mixing.
        When you show a JSP page you are writing in JSP stream, while when you use RequestDispatcher you are writing in HttpResponse stream

        Show
        Antonio Petrelli added a comment - In fact you are mixing. When you show a JSP page you are writing in JSP stream, while when you use RequestDispatcher you are writing in HttpResponse stream
        Hide
        Mck SembWever added a comment -

        not a problem using tiles-3.0

        Show
        Mck SembWever added a comment - not a problem using tiles-3.0
        Hide
        Mck SembWever added a comment -

        just testing jira wiki renderer

        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); }
        }
        Show
        Mck SembWever added a comment - just testing jira wiki renderer 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); } }

          People

          • Assignee:
            Unassigned
            Reporter:
            Mck SembWever
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development