[jira] Updated: (WICKET-3108) Problems with page maps stored in session

["Pedro Santos (JIRA)" <ji...@apache.org>]

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

Pedro Santos updated WICKET-3108:
---------------------------------

    Attachment: fix-WICKET-3108-memory-leak.patch

Patch removing the "usedPageMaps" list form the Session (was generation the memory leak) and using the session store information instead

> Problems with page maps stored in session
> -----------------------------------------
>
>                 Key: WICKET-3108
>                 URL: https://issues.apache.org/jira/browse/WICKET-3108
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.4.12
>            Reporter: Jeremy Thomerson
>            Assignee: Jeremy Thomerson
>            Priority: Minor
>             Fix For: 1.4.13
>
>         Attachments: fix-WICKET-3108-memory-leak.patch, pagemapstuff-quickstart.tar.gz, patch.txt, patch.txt, problem-1.patch, problem-2.patch, problem-3.patch, test.patch
>
>
> A client engaged me to assist in fixing multiple problems they found while writing a custom page map eviction strategy for page maps that have not been accessed in a while.  Digging into the first problem revealed a few others.  I'd like someone who is more familiar than me with the session and page map stuff to review this before I commit it.  The quick start attached demonstrates the problems.  I have yet to write test cases that can be added to the suite to replicate these issues.
> PROBLEM 1:
> If you call IPageMap.remove(), the page map is not actually removed because it's in the dirty objects list, which means that it gets set back on the session in the requestDetached() method.  The quickstart demonstrates this in a link for ease of demonstration, but in reality, it applies even if someone is doing custom page map eviction in their request cycle somewhere.
> PROBLEM 2:
> It seems to be a safe assumption that every page map that is used in the session should also be in usedPageMaps, and that this map should always be exactly in sync with what's actually in your session (as attributes).  Right now, they are not in sync.  First, the default page map was not added to usedPageMaps in the dirtyPageMap(IPageMap) method.  Second, when page maps are created, they are not dirtied (which means they are not in the usedPageMaps collection), although they are set as attributes on the session immediately.  This causes a problem in the newPageMap(String) method with actually adhering to the max number you set.
> PROBLEM 3:
> If you have a bunch of popup links on a page, they can create more page maps than are allowed, and the number of page maps stored in the session grows beyond the limit of what you've specified.  The real unanswered question I have is this: must we really create the page map when the link is first rendered?  Or could we wait until it is clicked?
> NOTE: the fix for problems 2 and 3 relies on the fix for problem 1 being committed, because the call to pm.remove() in newPageMap(IPageMap) will not work without the fix for problem 1

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