[jira] Commented: (WICKET-1365) Having instance variables referencing pages causes memory leaks, StackOverflowErrors and ClassCastExceptions

["Matej Knopp (JIRA)" <ji...@apache.org>]

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

Matej Knopp commented on WICKET-1365:
-------------------------------------

 I've commited fix for this problem. Can you please check if it fixes the OOM for you?

> Having instance variables referencing pages causes memory leaks, StackOverflowErrors and ClassCastExceptions
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: WICKET-1365
>                 URL: https://issues.apache.org/jira/browse/WICKET-1365
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.3.1
>            Reporter: Henrik Lundahl
>            Assignee: Matej Knopp
>             Fix For: 1.3.2
>
>         Attachments: ModalWindowTest.zip
>
>
> Having references (instance variables), in objects reachable from the component hierarchy, to pages other than the "current" page, causes memory leaks StackOverflowErrors and sometimes ClassCastExceptions.
> This seems to be due to the special serialization code implemented in Page, even if I haven't been able to pinpoint exactly where the problem lies. Standard serialization handles cycles between objects if the deserialization or serialization is done using the same ObjectInputStream or ObjectOutputStream, but here each Page is being deserialized in different ObjectInputStreams.
> Looking at the stack traces from the StackOverflowErrors it's easy to see that it's the deserialization that goes over the same pages over and over again (although it's new instances).
> The ClassCastExceptions where because the Page.numericId was zero when serializing them in Page.writeObject, causing the wrong Page to be deserialized in readObject. By looking at the code I can't really understand how the numericId can become zero, except for in the first page. The only thing I can think of is if it's being serialized by another thread before it's initialized.
> Our application is "AJAX only" with a main page built up of quite a lot of components in a quite deep hierarchy. When discovering this problem, there was one panel with seven different AjaxLinks that opened ModalWindows, where some of the ModalWindows had fields referencing the contained iframe pages. Clicking around on the links soon made the memory and CPU consumption rise and after a while one of the mentioned errors occurred.
> Even if I thought that it would, neither turning off page versioning nor setting ISessionSettings.setPageIdUniquePerSession(true) seemed to have any effect.
> After redesigning the code a bit, removing all the field references to Pages, it seems to work fine again. I realize that having such references isn't a very good design even without this problem. Perhaps it shouldn't be supported at all. It might be, though, that some users have done this and don't know it's a problem (yet).
> Although in the above case it was only AJAX, I've made an example application that also shows that the same problems occurs using normal links, and pages with references between them. I'll attach that example in a couple of minutes.

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