[ http://issues.apache.org/jira/browse/BEEHIVE-1105?page=all ]
Carlin Rogers resolved BEEHIVE-1105:
------------------------------------
Resolution: Fixed
Assign To: Julie Zhuo (was: Carlin Rogers)
This is fixed with revision 397224. See...
http://svn.apache.org/viewcvs?rev=397224&view=rev
Also, in revision 396594 ( http://svn.apache.org/viewcvs?rev=396594&view=rev )
I removed an unused field and its initialization from the FlowController class.
This helps performance by reducing another call to get the ActionServlet
attribute from the ServletContext on each reinitialize().
The NetUI BVT passed.
> Perf bottleneck with the number of calls from PageFlowPageFilter to get
> ActionServlet from ServletContext
> ---------------------------------------------------------------------------------------------------------
>
> Key: BEEHIVE-1105
> URL: http://issues.apache.org/jira/browse/BEEHIVE-1105
> Project: Beehive
> Type: Improvement
> Components: NetUI
> Versions: 1.0.1
> Reporter: Carlin Rogers
> Assignee: Julie Zhuo
> Fix For: v.next
>
> Perf issue - for JSP not associated directly to a page flow, there are
> multiple calls via the PageFlowPageFilter to get ActionServlet from
> ServletContext. Some containers, implement the ServletContext getAttribute()
> method with synchronization on the attribute object or the attributes map.
> An application that includes common JSP not associated with a given page flow
> (for look and feel, banners, headers, or footers) will experience a
> synchronization bottleneck under heavy load. For example, a page flow action
> may forward to a JSP which includes a few other JSP for a header and footer
> (like... <jsp:include page="../common/header.jsp"/> where there's no
> associated page flow or struts module config for the location of the common
> header JSP). The JSP include will go through the PageFlowPageFilter. The
> filter now tries to ensure a module config from a module path when
> initializing the module, getting the shared flows for the request and trying
> to get the page flow for the request. All these calls go through the
> InternalUtils.ensureModuleConfig(), making a call to get the ActionServlet
> (the NetUI AutoRegisterActionServlet) from the ServletContext attributes.
> Note that this will happen on every include of this example header JSP for a
> given request. If this file, and others like it are used in most of the pages
> of the application and there are many users applying load, there will be a
> bottleneck in the multiple calls to the ServletContext getAttribute() method
> from each of the requests.
> Note that his particular bug is just one aspect of performance improvements
> that could be made for getting data associated with a given module path.
> Would be great to implement some sort of caching layer to provide a
> central/common way to access to module configs, shared flow information, etc.
> without having to get the Netui AutoRegisterActionServlet directly. I will
> log a future enhancement in JIRA to improve on any short term fixes in this
> bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
