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

Hudson commented on WICKET-3108:
--------------------------------

Integrated in Apache Wicket 1.4.x #266 (See 
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/266/])
    

> 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.

Reply via email to