[WICKET-1667] Memory leak in Localizer

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.3.3, 1.4-M1
• Fix Version/s: 1.3.4, 1.4-M3
• Assignee: Igor Vaynberg
• Reporter: Frédéric Donckels
• Created: 27/May/08 15:09
• Updated: 14/Oct/11 18:31
• Resolved: 16/Jun/08 15:52

Description

I noticed recently (and told on IRC) a problem with the Localizer and the way the getCacheKey() method works.

I uses the component id of all component in the path to the component to create the key. But each page generation has a different id. This has been fixed recently by breaking outside of the loop which creates the key if the component's parent is a Page instance. This partially solves the always increasing cache. But it still has some issues:

• with the page completely outside of the path, it could introduce some rare bugs when searching for keys defined in the page properties file (it shouldn't break but skip the "buffer.append(":").append(cursor.getId())" when the cursor is on a Page instance).
• there is still a bunch of ids generated when you loop over a repeater (the component of type Item has a new id for every item in the list). this is mitigated by the fact that when doing a normal refresh of the view, the starting id restarts at 1, but if you have an Ajax paging view, it's not restarted and starts again to fill the cache with unwanted keys.

there are multiple options:

• never include the id in the key (I'm not convinced it is necessary; is it really used in the String loader?)
• don't include the id in the key if the cursor is on a component of type Page or Item
• don't include the id if it's numeric (is this costly?)

In the meantime, I'll make a small fix in my local checkout of Wicket, not including the id if the cursor is on Page or Item

Issue Links

• is cloned by: WICKET-4133 Re-Open - Memory leak in Localizer
• is related to: WICKET-1697 Bad caching in <wicket:message> tag for the same key in same markup structure