You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Badaud (JIRA)" <ji...@apache.org> on 2008/06/04 09:38:45 UTC

[jira] Commented: (WICKET-1667) Memory leak in Localizer

    [ https://issues.apache.org/jira/browse/WICKET-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602210#action_12602210 ] 

Badaud commented on WICKET-1667:
--------------------------------

Hi,

Any idea why the patch didn't make it into 1.4-m2?

> Memory leak in Localizer
> ------------------------
>
>                 Key: WICKET-1667
>                 URL: https://issues.apache.org/jira/browse/WICKET-1667
>             Project: Wicket
>          Issue Type: Bug
>    Affects Versions: 1.3.3, 1.4-M1
>            Reporter: Badaud
>            Assignee: Igor Vaynberg
>         Attachments: patch.txt
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> 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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.