[
https://issues.apache.org/struts/browse/STR-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41742
]
Paul Benedict commented on STR-3056:
------------------------------------
Message resources are on the classpath and JVMs pre-6.0 cannot reload/change
those. However, that's not true since JDK 6:
http://java.sun.com/javase/6/docs/api/java/util/ResourceBundle.Control.html
The issue, while problematic for some use cases, is not a bug. I marked this as
an improvement for 1.4 only because I foresee a backwards compatibility
problem. I recommend a flag to be added to message resources to control whether
caching should happen also for cache misses.
What do you say Niall?
> 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.3.10, 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.