[
https://issues.apache.org/jira/browse/WICKET-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johan Compagner updated WICKET-1370:
------------------------------------
Attachment: markuppatch.txt
We pretty much already had the interface we wanted for this
(IFixedLocationResourceStream). I only needed to let MarkupResourceStream also
implement it.
And then MarkupCache uses that interface to checkout what the actual file is
I dont think we will get IResourceStream implementation that are not File or
URL and if we do then we fallback on the cachekey only approache.
It seems to work fine for me when i test locally, the markup is only created
once per fixed location and then access through
cachekey -> locationstring -> markup
So if locationString doesn't work we get this:
cachekey -> cachekey -> markup
But i guess that is a very small percentage if there is even 1 on this planet...
should we include this into 1.3.2?
> 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
> 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.
