[
https://issues.apache.org/struts/browse/STR-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41951
]
Patrick HIggins commented on STR-3056:
--------------------------------------
returnNull reduced the memory problem very slightly. The problem isn't creating
the return value, but all the keys that are used in messages.get(key) calls.
We've decided to subclass PropertyMessageResources already. First we were doing
our own caching, but Niall's suggestion to return null for these special keys
rather than caching is good, and we're trying that out now, and is probably
what we'll go with.
I'm pretty sure it will create more garbage than my caching strategy did, but
we don't have to worry about bizarre bugs involving locale load orders.
Thanks for the ideas!
> 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
>
>
> 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.
