Description
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.