[jira] Updated: (STR-3056) PropertyMessageResources.getMessage() does not cache failed lookups

["Patrick HIggins (JIRA)" <ji...@apache.org>]

     [ 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_cache_null.patch

Here's a refinement of the previous patch that includes a cacheNull property on PropertyMessageResources and PropertyMessageResourcesFactory which will allow less work to be done when looking up a key that won't be found.

I may submit a third patch that includes this functionality without the big refactor of String keys to MessageKey keys.

Let me know what you think.

> 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, message_resources_cache_null.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.