try applying this patch and see if it helps
https://issues.apache.org/jira/browse/WICKET-1667
-igor
On Mon, Jun 9, 2008 at 8:11 AM, Stefan Fußenegger
<[EMAIL PROTECTED]> wrote:
>
> I am just analysing a heap dump (god bless the
> -XX:+HeapDumpOnOutOfMemoryError flag) of a recent application cache due to
> an OutOfMemoryError ("GC overhead limit exceeded" to be precise). Using
> jhat, the "175456 instances of class
> org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry" immediately got
> my attention. While looking through the 107 instance of ConcurrentHashMap, I
> found one *really* big one: Localizer.cache has a hash table length of
> 262144, each of its 32 segments with about 5300 entries, where a hash key is
> a string, sometimes longer than 500 charactes, similar to (see
> Localizer.getCacheKey(String,Component)):
>
> fooTitle.bar-org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink-org.apache.wicket.markup.html.panel.Fragment:track-org.apache.wicket.markup.html.list.ListItem:14-my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos-org.apache.wicket.markup.html.list.ListItem:0-my.company.BarListPanel$1:bars-my.company.FooListPanel:panel-my.company.boxes.BodyBox:2-org.apache.wicket.markup.repeater.RepeatingView:body-my.company.layout.Border:border-my.company.pages.music.FoobarPage:43-de-null
>
> Those numbers pretty much convinced me: The localizer cache has blown away
> my application.
>
> Looking at this hash keys, I suspect the following problem: those strings
> are constructed from the "position" of a localized String on a page, which
> is quite a bad thing if you use nested list views or repeating views to
> construct your page. For instance, I have a panel with a long (pageable)
> list of entries, might be > 5000 entries which might appear on various
> positions in a repeating view I use as a container for most of my pages.
> Let's say there are 5 possible positions, this would cause 2500 thousand
> cached entries, each with a key of 300+ characters plus some more characters
> for the cached message - feel free to do the maths. From a quick estimate
> I'd say: No wonder, this has blown away my app.
>
> As a quick fix, I'd suggest to regularly clear the localizer cache, use a
> more sophisticated cache (that expires old entries once in a while!!) or to
> disable the cache completely. However, don't try to overwrite
> Localizer.newCache() and clear the cache regularly: clearCache() will
> replace your cache with a ConcurrentHashMap (not using
> Localizer.newCache()). However, quite unlikely, that this will happen as
> newCache() is private anyway ;) I am going to add some code to clear the
> cache regularly.
>
> Best regards, Stefan
>
> PS: I'll also create a JIRA issue, but I am really short on time right now.
>
> -----
> -------
> Stefan Fußenegger
> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> --
> View this message in context:
> http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p17734931.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
