[jira] Resolved: (WW-2189) improve freemarker first-level template caching

["Don Brown (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/struts/browse/WW-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Don Brown resolved WW-2189.
---------------------------

    Resolution: Fixed
      Assignee: Don Brown

Fixed, thanks for the nice patch!

> improve freemarker first-level template caching
> -----------------------------------------------
>
>                 Key: WW-2189
>                 URL: https://issues.apache.org/struts/browse/WW-2189
>             Project: Struts 2
>          Issue Type: Improvement
>          Components: Plugin - Tags
>    Affects Versions: 2.0.10
>            Reporter: Haroon Rafique
>            Assignee: Don Brown
>            Priority: Minor
>             Fix For: 2.1.1
>
>         Attachments: ww-2189-max-strong-size-mrucache.patch
>
>
> I think the freemarker first-level caching needs to be improved. The default cache used by freemarker implements a two-level Most Recently Used cache. In the first level, items are strongly referenced up to the specified maximum (strongly referenced items can't be dropped by the JVM, as opposed to softly referenced items). When the maximum is exceeded, the least recently used item is moved into the second level cache, where they are softly referenced, up to another specified maximum.
> Quoting from (near the bottom):
> http://freemarker.org/docs/pgui_config_templateloading.html#pgui_config_templateloading_caching
> When you create a new Configuration object, initially it uses an MruCacheStorage where maxStrongSize is 0, and maxSoftSize is Integer.MAX_VALUE (that is, in practice, infinite). But using non-0 maxStrongSize is maybe a better strategy for high load servers, since it seems that, with only softly referenced items, JVM tends to cause just higher resource consumption if the resource consumption was already high, because it constantly throws frequently used templates from the cache, which then have to be re-loaded and and re-parsed.
> The patch (will be attached shortly) against 2.0.10 configures a non-zero value for the first-level cache.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.