You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@tiles.apache.org by "Mck SembWever (JIRA)" <ji...@apache.org> on 2011/03/09 09:11:59 UTC
[jira] Created: (TILES-522) Performance of TemplateAttributeRender
in Tomcat
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
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);
}
}
Maybe it's possible to apply this code? Or better yet maybe there's a better place to apply it? (I've created the issue to spawn the discussion...i'm not totally convince myself this is code that should be committed...)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TILES-522) Performance of TemplateAttributeRender
in Tomcat
Posted by "Mck SembWever (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mck SembWever updated TILES-522:
--------------------------------
Attachment: TILES-522.patch
Suggested patch to JspTilesRequestContext
> 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
[jira] Updated: (TILES-522) Performance of TemplateAttributeRender
in Tomcat
Posted by "Mck SembWever (JIRA)" <ji...@apache.org>.
[ 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, 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?
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);
}
}
Maybe it's possible to apply this code? Or better yet maybe there's a better place to apply it? (I've created the issue to spawn the discussion...i'm not totally convince myself this is code that should be committed...)
> 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, 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?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TILES-522) Performance of TemplateAttributeRender
in Tomcat
Posted by "Mck SembWever (Closed) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mck SembWever closed TILES-522.
-------------------------------
Resolution: Won't Fix
not a problem using tiles-3.0
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TILES-522) Performance of
TemplateAttributeRender in Tomcat
Posted by "Mck SembWever (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212875#comment-13212875 ]
Mck SembWever commented on TILES-522:
-------------------------------------
*just testing jira wiki renderer*
For example we have overridden TemplateAttributeRender like
{code}
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); }
}{code}
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TILES-522) Performance of TemplateAttributeRender
in Tomcat
Posted by "Mck SembWever (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (TILES-522) Performance of
TemplateAttributeRender in Tomcat
Posted by "Mck SembWever (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004995#comment-13004995 ]
Mck SembWever commented on TILES-522:
-------------------------------------
Yes of course. It is was in TemplateAttributeRender because we already had that class custom in our application.
I will test it in JspTilesRequestContext.
> 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
[jira] Commented: (TILES-522) Performance of
TemplateAttributeRender in Tomcat
Posted by "Antonio Petrelli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004527#comment-13004527 ]
Antonio Petrelli commented on TILES-522:
----------------------------------------
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
> 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, 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?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TILES-522) Performance of
TemplateAttributeRender in Tomcat
Posted by "Mck SembWever (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053683#comment-13053683 ]
Mck SembWever commented on TILES-522:
-------------------------------------
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?
> 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
[jira] [Commented] (TILES-522) Performance of
TemplateAttributeRender in Tomcat
Posted by "Antonio Petrelli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053689#comment-13053689 ]
Antonio Petrelli commented on TILES-522:
----------------------------------------
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
> 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
[jira] [Issue Comment Edited] (TILES-522) Performance of
TemplateAttributeRender in Tomcat
Posted by "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 edited comment on TILES-522 at 6/22/11 6:34 PM:
--------------------------------------------------------------
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.
was (Author: michaelsembwever):
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
[jira] [Commented] (TILES-522) Performance of
TemplateAttributeRender in Tomcat
Posted by "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
[jira] [Commented] (TILES-522) Performance of
TemplateAttributeRender in Tomcat
Posted by "Antonio Petrelli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053680#comment-13053680 ]
Antonio Petrelli commented on TILES-522:
----------------------------------------
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.
> 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