[
https://issues.apache.org/jira/browse/WICKET-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp resolved WICKET-1365.
---------------------------------
Resolution: Fixed
> 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.
