[
https://issues.apache.org/jira/browse/WICKET-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johan Compagner resolved WICKET-1370.
-------------------------------------
Resolution: Fixed
Assignee: Johan Compagner
ok i committed it.
This should be looked at a bit more to see if for example all the interaction
with the cache works now
Especially the reloading/removing of markup
> MarkupCache can "leak" memory
> -----------------------------
>
> Key: WICKET-1370
> URL: https://issues.apache.org/jira/browse/WICKET-1370
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.1
> Reporter: Igor Vaynberg
> Assignee: Johan Compagner
> Priority: Critical
> Fix For: 1.3.2
>
> Attachments: markuppatch.txt, WICKET-1370.patch.txt
>
>
> Currently markup cache uses a cache without any capacity upper bound :|
> normally this would be ok, holding markup of an entire application doesnt
> require THAT much memory. However, suppose we have Index page with markup
> Index.html. the page is requested with local en_us and we cache contents of
> index.html in the cache. now Index is requested with locale en_gb and we
> cache it AGAIN. Now we have two entries in the cache caching the exact same
> thing. the more locales users request (we pull the locale from the user's
> browser) the more copies of the same thing we cache.
> Thomas Singer reported his application running out of memory, attached memory
> snapshot contained a MarkupCache instance of over 48MB retained size (the
> internal map had allocated 4096 keys). He has an application with about 64
> pages, and they only support one locale. When I browsed the snapshot I
> noticed a lot of different locales in the markup cache keys....
> An ideal solution would be to have two caches. One for
> [container.class,locale,style,variation]->[resource.name] lookup, and the
> other for [resource.name]->[resource.contents] lookup.
> A suboptimal solution would be to place an upper bound on the cache. See
> attached patch which contains a 1000 item lru cache. if looks ok we can roll
> it in as a solution for 1.3.2 branch - since it doesnt require any interfaces
> breakages.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
