You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Igor Vaynberg (JIRA)" <ji...@apache.org> on 2008/02/25 21:20:51 UTC
[jira] Created: (WICKET-1370) MarkupCache can "leak" memory
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.
[jira] Resolved: (WICKET-1370) MarkupCache can "leak" memory
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (WICKET-1370) MarkupCache can "leak" memory
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (WICKET-1370) MarkupCache can "leak" memory
Posted by "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.