You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Haroon Rafique (JIRA)" <ji...@apache.org> on 2007/09/17 22:56:36 UTC
[jira] Created: (WW-2189) improve freemarker first-level template
caching
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: Views
Affects Versions: 2.0.10
Reporter: Haroon Rafique
Priority: Minor
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.
[jira] Resolved: (WW-2189) improve freemarker first-level template
caching
Posted by "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.
[jira] Updated: (WW-2189) improve freemarker first-level template
caching
Posted by "James Holmes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James Holmes updated WW-2189:
-----------------------------
Fix Version/s: (was: 2.0.11)
2.0.12
> 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: Views
> Affects Versions: 2.0.10
> Reporter: Haroon Rafique
> Priority: Minor
> Fix For: 2.0.12
>
> 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.
[jira] Updated: (WW-2189) improve freemarker first-level template
caching
Posted by "Haroon Rafique (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Haroon Rafique updated WW-2189:
-------------------------------
Attachment: ww-2189-max-strong-size-mrucache.patch
Patch against 2.0.10 which implements a non-zero value for first-level MRU cache setting for freemarker.
> 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: Views
> Affects Versions: 2.0.10
> Reporter: Haroon Rafique
> Priority: Minor
> 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.
[jira] Updated: (WW-2189) improve freemarker first-level template
caching
Posted by "James Holmes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James Holmes updated WW-2189:
-----------------------------
Fix Version/s: 2.0.11
> 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: Views
> Affects Versions: 2.0.10
> Reporter: Haroon Rafique
> Priority: Minor
> Fix For: 2.0.11
>
> 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.