another possible solution is to serialize the page into SerializedPage
before sticking it into session...this may introduce some overhead,
especially for non-clustered apps. however, we can have a special
pagemanager for non-clustered apps that does not change page instances
into SerializedPage...kind of like HttpSessionStore works in 1.4
compared to a store that uses DiskPageStore.

-igor


On Fri, Mar 18, 2011 at 9:35 AM, Martin Grigorov <[email protected]> wrote:
> On Fri, Mar 18, 2011 at 5:04 PM, tetsuo <[email protected]> wrote:
>
>> Well, I was trying to understand the problem before posting random thoghts
>> :)
>>
>> SegFault commented the issue with this question:
>>
>> > " the only problem I see is that there is no one to clean the static
>> > org.apache.wicket.page.PersistentPageManager.managers" <= maybe a stupid
>> question,
>> > but how does this behave in case of many context reloading (for example
>> in developpement
>> > mode), is this cleaned up by container ? or this will end up with a
>> PermGen space error ?
>>
>> I think that, unless you hold references to webapp-specific classes in
>> server-loaded classes' static fields, or leave zombie threads, PermGen
>> shouldn't occur, and all classes should be gc'ed. Does the page
>> manager do anything that prevents it to be gc'ed? Does it need any
>> extra clean-up, besides being unloaded with the webapp classloader?
>>
>> The problem is that the web container first destroys WicketFilter and then
> goes to serialize/persist the session.
> Wicket puts Page instances in the session, but before serialization these
> Page instances are transformed to SerializedPage which is a struct of
>   int pageId;
>   String sessionId;
>   byte[] data;  // the page itself
>
> and to be able to transform them Wicket needs the configured IPageManager.
> With the destroy of WicketFilter all information is removed (null-ified)
> including the PageManager and thus the serialization fails.
>
> With the new ServletContextListener (SCL) we will move the application start
> and stop from the Filter to SCL and solve this problem.
>
> Additionally by Servlet specification the container may restart
> servlets/filters at any time without completely stopping the application,
> i.e. w/o
> calling 
> javax.servlet.ServletContextListener.contextDestroyed(ServletContextEvent).
> So the new way will improve the current behavior.
>
>>
>>
>> On Fri, Mar 18, 2011 at 12:42 PM, Igor Vaynberg <[email protected]>
>> wrote:
>> > i would say that the lack of response shows that people dont care
>> > about a couple more xml lines they have to add to web.xml once and
>> > forget about.
>> >
>> > -igor
>> >
>> > On Fri, Mar 18, 2011 at 7:47 AM, Martin Grigorov <[email protected]>
>> wrote:
>> >> On Thu, Mar 17, 2011 at 10:54 PM, Martin Grigorov <[email protected]
>> >wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> To solve https://issues.apache.org/jira/browse/WICKET-3470 we need to
>> >>> introduce ServletContextListener in Wicket.
>> >>> In comment
>> >>>
>> https://issues.apache.org/jira/browse/WICKET-3470?focusedCommentId=13008166&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13008166Idescribed
>>  a proposal how we can change web.xml configuration to make it
>> >>> working. The proposal is based on a discussion between me and Igor in
>> IRC.
>> >>>
>> >>> This is a rather big change and we need more opinions, so please share
>> if
>> >>> you have ideas.
>> >>>
>> >>
>> >> By "big" here I mean conceptually, not code wise. Technically it doesn't
>> >> seem to be big or complex.
>> >>
>> >>>
>> >>> --martin-g
>> >>>
>> >>> P.S. I'm interested to understand why there is no such problem with
>> Wicket
>> >>> 1.4?
>> >>> I guess sessions in 1.4 are cleared earlier and never persisted between
>> web
>> >>> container restarts.
>> >>>
>> >>> --
>> >>> Martin Grigorov
>> >>> jWeekend
>> >>> Training, Consulting, Development
>> >>> http://jWeekend.com <http://jweekend.com/>
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Martin Grigorov
>> >> jWeekend
>> >> Training, Consulting, Development
>> >> http://jWeekend.com <http://jweekend.com/>
>> >>
>> >
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com <http://jweekend.com/>
>

Reply via email to