[
https://issues.apache.org/struts/browse/STR-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick HIggins updated STR-3056:
---------------------------------
Attachment: message_resources.patch
Patch which allocates much less memory, but changes protected APIs, so
subclasses would be broken.
The patch mainly changes from using String keys to MessageKey instances which
store String locale and String key fields separately, but this allows to change
the locale to another String during the search without having to allocate more
storage for it.
Also, the locale search path (en_US -> en -> "") is stored in a static cache
keyed by Locale to save computation and substring operations.
This should make lookups allocate a lot less garbage.
> PropertyMessageResources.getMessage() does not cache failed lookups
> -------------------------------------------------------------------
>
> Key: STR-3056
> URL: https://issues.apache.org/struts/browse/STR-3056
> Project: Struts 1
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.1.0, 1.3.8
> Environment: Applies to all environments
> Reporter: Patrick HIggins
> Fix For: 1.4.0
>
> Attachments: message_resources.patch
>
>
> We have an application that allocates lots of garbage (sometimes over 100MB)
> when rendering a single page. After using Netbeans profiler with it, I've
> found that a lot of that garbage is created by MessageResources.messageKey().
> It appears that we are calling bean:write (WriteTag) thousands of times, and
> it looks up the message for "org.apache.struts.taglib.bean.format.int" to try
> to find a default format for integers. We have not defined this property in
> our ApplicationResources, so it ends up returning the value
> "???en_US.org.apache.struts.taglib.bean.format.int???" after searching
> exhaustively for it. It does not cache this value. Then, when we call it the
> next 8,000 times, it performs the same exhaustive search over and over
> because it's not caching the negative response.
> I propose that negative responses get cached, too. That would save a lot of
> time and memory so that WriteTag can just go ahead and call toString() on the
> instance of java.lang.Integer.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
