[jira] Updated: (WICKET-1370) MarkupCache can "leak" memory

["Igor Vaynberg (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Igor Vaynberg updated WICKET-1370:
----------------------------------

    Attachment: WICKET-1370.patch.txt

> 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: 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.