[
https://issues.apache.org/jira/browse/MYFACES-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896060#action_12896060
]
Michael Concini commented on MYFACES-2864:
------------------------------------------
One other point of discussion is whether since the cache maps use a classloader
reference as a key to ensure we get the paths associated with the individual
webapp on servers with more than one app, would a WeakHashMap be safer to make
sure that we don't prevent classloaders from being GC'd on a redeploy/restart?
> Allow caching of resources by the default external context impl
> ---------------------------------------------------------------
>
> Key: MYFACES-2864
> URL: https://issues.apache.org/jira/browse/MYFACES-2864
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
> Affects Versions: 2.0.2-SNAPSHOT
> Reporter: Michael Concini
> Assignee: Michael Concini
> Attachments: MYFACES-2864-patch.txt
>
>
> We've seen in our testing significant improvements in performance by caching
> the results of getResource() and getResourcePaths() calls. Adding this
> caching has led to about a 30% increase in throughput on an older JSP
> application, and a doubling of throughput on JSF2/facelets applications that
> utilize templating and composite components. This testing was all done on
> WAS so gains could be different on other servers depending on the behavior of
> their servlet containers.
> In the patch I'm attaching, it currently sets that the default for the
> caching is enabled if the project stage is production and I've defaulted the
> cache size to 500 entries. I've created two context params that allow for
> overriding the size and/or disabling the cache outright.
> There might be a few cases where this will need to be disabled. Most
> prominently would be anyone who adds or removes files to a production
> environment. This could cause problems for an application that generates
> dynamic content on disk instead of in memory, although I don't know if that
> is common enough that we'd want to turn it off by default given the gains
> that the majority of users would see.
> Please review the patch and let me know if there should be any tweaks or if
> anyone feels strongly one way or the other about whether it should be enabled
> or disabled by default. I'll plan on committing Monday based on any consensus.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
