Re: HEADS UP: A change in web.xml setup is required
On Thu, Mar 17, 2011 at 10:54 PM, Martin Grigorov mgrigo...@apache.orgwrote: 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=13008166page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13008166I described 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/
Re: HEADS UP: A change in web.xml setup is required
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 mgrigo...@apache.org wrote: On Thu, Mar 17, 2011 at 10:54 PM, Martin Grigorov mgrigo...@apache.orgwrote: 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=13008166page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13008166I described 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/
Re: HEADS UP: A change in web.xml setup is required
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? On Fri, Mar 18, 2011 at 12:42 PM, Igor Vaynberg igor.vaynb...@gmail.com 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 mgrigo...@apache.org wrote: On Thu, Mar 17, 2011 at 10:54 PM, Martin Grigorov mgrigo...@apache.orgwrote: 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=13008166page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13008166I described 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/
Re: Removing Pagemap lock post 1.5?
What about AJAX requests coming from multiple places for the same session? On Fri, Mar 18, 2011 at 11:45 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: I'm not sure if this is still happening in 1.5, but could it be possible to nix the pagemap lock (or severely shorten it to 1-2 seconds) and abandon request processing at the first possible moment when a new request for the pagemap arrives at the server? It's not like the browser is expecting an answer for the original request AFAIK. Expected behavior: - request1: starts processing, locks pagemap - request2: comes in: tries to acquire lock - request2: waits for max N seconds (N being a small number, 1 or 2 seconds) - request2: sets kill switch for request1 - request1: first time in wicket managed code: throws Abort exception, does not commit page hierarchy to pagemap - request2: starts processing its request Probably this will become quite complex and I have my friday afternoon goggles on, so just think of this as a thought experiment. Homework: think out what happens when request3 joins the party. Martijn
Re: HEADS UP: A change in web.xml setup is required
On Fri, Mar 18, 2011 at 5:04 PM, tetsuo ronald.tet...@gmail.com 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 igor.vaynb...@gmail.com 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 mgrigo...@apache.org wrote: On Thu, Mar 17, 2011 at 10:54 PM, Martin Grigorov mgrigo...@apache.org 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=13008166page=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/
Re: Removing Pagemap lock post 1.5?
Can you tell us what is the actual problem ? :-) Recently I made some brave hacks experimenting with 1.5 PageAccessSynchronizer and I can say that everything is possible but then Igor reminded me how bad is to remove this synchronization and what bad things can start to happen. On Fri, Mar 18, 2011 at 4:45 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: I'm not sure if this is still happening in 1.5, but could it be possible to nix the pagemap lock (or severely shorten it to 1-2 seconds) and abandon request processing at the first possible moment when a new request for the pagemap arrives at the server? It's not like the browser is expecting an answer for the original request AFAIK. Expected behavior: - request1: starts processing, locks pagemap - request2: comes in: tries to acquire lock - request2: waits for max N seconds (N being a small number, 1 or 2 seconds) - request2: sets kill switch for request1 - request1: first time in wicket managed code: throws Abort exception, does not commit page hierarchy to pagemap - request2: starts processing its request Probably this will become quite complex and I have my friday afternoon goggles on, so just think of this as a thought experiment. Homework: think out what happens when request3 joins the party. Martijn -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: HEADS UP: A change in web.xml setup is required
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 mgrigo...@apache.org wrote: On Fri, Mar 18, 2011 at 5:04 PM, tetsuo ronald.tet...@gmail.com 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 igor.vaynb...@gmail.com 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 mgrigo...@apache.org wrote: On Thu, Mar 17, 2011 at 10:54 PM, Martin Grigorov mgrigo...@apache.org 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=13008166page=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/
Re: Removing Pagemap lock post 1.5?
Expected behavior: - request1: starts processing, locks pagemap - request2: comes in: tries to acquire lock - request2: waits for max N seconds (N being a small number, 1 or 2 seconds) - request2: sets kill switch for request1 - request1: first time in wicket managed code: throws Abort exception, does not commit page hierarchy to pagemap this step can be quite complex, because at what stage is that? Also long request are very likely not touching any wicket code but those are in queries and so on besides that we must make sure that the object hiearchy and so on is not suddenly in a wrong state. And there are cases that request 1 is still way more important then request 2 and request 2 may never just kill 1. (Request 2 is just a background polling thread of are there any changes) - request2: starts processing its request
Re: Removing Pagemap lock post 1.5?
On Fri, Mar 18, 2011 at 6:01 PM, Johan Compagner jcompag...@gmail.com wrote: besides that we must make sure that the object hiearchy and so on is not suddenly in a wrong state. That is the idea: the object hierarchy should not be put into the page store—essentially throwing away any changes made during that partially processed request. And there are cases that request 1 is still way more important then request 2 and request 2 may never just kill 1. (Request 2 is just a background polling thread of are there any changes) Request 2 will only complete when request 1 is finished, so much for polling :). In most if not all cases where request1 takes longer than 10 seconds, it should be done in a background thread. Unfortunately JEE does not provide a good way to facilitate that. A bigger issue is that when request 1 has finished processing the listener phase, but rendering the response takes too long. What should happen in that instance? Martijn
Re: HEADS UP: A change in web.xml setup is required
in general I prefer correctness over convenience ... so if we need a context listener to do everything right so should it be (remember having the same kind of trouble with jetty) +0 Am 18.03.2011 um 17:50 schrieb Igor Vaynberg: 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 mgrigo...@apache.org wrote: On Fri, Mar 18, 2011 at 5:04 PM, tetsuo ronald.tet...@gmail.com 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 igor.vaynb...@gmail.com 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 mgrigo...@apache.org wrote: On Thu, Mar 17, 2011 at 10:54 PM, Martin Grigorov mgrigo...@apache.org 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=13008166page=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/
Re: HEADS UP: A change in web.xml setup is required
Why would it (Igor's proposal) be not correct? On Fri, Mar 18, 2011 at 2:28 PM, Peter Ertl pe...@gmx.org wrote: in general I prefer correctness over convenience ... so if we need a context listener to do everything right so should it be (remember having the same kind of trouble with jetty) +0 Am 18.03.2011 um 17:50 schrieb Igor Vaynberg: 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 mgrigo...@apache.org wrote: On Fri, Mar 18, 2011 at 5:04 PM, tetsuo ronald.tet...@gmail.com 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 igor.vaynb...@gmail.com 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 mgrigo...@apache.org wrote: On Thu, Mar 17, 2011 at 10:54 PM, Martin Grigorov mgrigo...@apache.org 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=13008166page=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/
Re: HEADS UP: A change in web.xml setup is required
I don't think he was saying it was incorrect. He was saying that he's okay with the added inconvenience if it makes everything work correctly. On Fri, Mar 18, 2011 at 1:51 PM, tetsuo ronald.tet...@gmail.com wrote: Why would it (Igor's proposal) be not correct? On Fri, Mar 18, 2011 at 2:28 PM, Peter Ertl pe...@gmx.org wrote: in general I prefer correctness over convenience ... so if we need a context listener to do everything right so should it be (remember having the same kind of trouble with jetty) +0 Am 18.03.2011 um 17:50 schrieb Igor Vaynberg: 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 mgrigo...@apache.org wrote: On Fri, Mar 18, 2011 at 5:04 PM, tetsuo ronald.tet...@gmail.com 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 igor.vaynb...@gmail.com 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 mgrigo...@apache.org wrote: On Thu, Mar 17, 2011 at 10:54 PM, Martin Grigorov mgrigo...@apache.org 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=13008166page=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/
Re: HEADS UP: A change in web.xml setup is required
Thus the +0, not -1. Duh, sorry... On Fri, Mar 18, 2011 at 3:01 PM, James Carman ja...@carmanconsulting.com wrote: I don't think he was saying it was incorrect. He was saying that he's okay with the added inconvenience if it makes everything work correctly. On Fri, Mar 18, 2011 at 1:51 PM, tetsuo ronald.tet...@gmail.com wrote: Why would it (Igor's proposal) be not correct? On Fri, Mar 18, 2011 at 2:28 PM, Peter Ertl pe...@gmx.org wrote: in general I prefer correctness over convenience ... so if we need a context listener to do everything right so should it be (remember having the same kind of trouble with jetty) +0 Am 18.03.2011 um 17:50 schrieb Igor Vaynberg: 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 mgrigo...@apache.org wrote: On Fri, Mar 18, 2011 at 5:04 PM, tetsuo ronald.tet...@gmail.com 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 igor.vaynb...@gmail.com 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 mgrigo...@apache.org wrote: On Thu, Mar 17, 2011 at 10:54 PM, Martin Grigorov mgrigo...@apache.org 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=13008166page=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/
Re: Removing Pagemap lock post 1.5?
In 1.5 I think it is improved because now the synchronization is on page instance (version) not on pagemap. So it is more fine grained. On Fri, Mar 18, 2011 at 6:07 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Fri, Mar 18, 2011 at 6:01 PM, Johan Compagner jcompag...@gmail.com wrote: besides that we must make sure that the object hiearchy and so on is not suddenly in a wrong state. That is the idea: the object hierarchy should not be put into the page store—essentially throwing away any changes made during that partially processed request. And there are cases that request 1 is still way more important then request 2 and request 2 may never just kill 1. (Request 2 is just a background polling thread of are there any changes) Request 2 will only complete when request 1 is finished, so much for polling :). In most if not all cases where request1 takes longer than 10 seconds, it should be done in a background thread. Unfortunately JEE does not provide a good way to facilitate that. Actually it does - Servlet 3's AsyncContext (aka Jetty Continuations) but I think this way it will be very hard for the application programmer. Context can switch at any time and someone has to take care to synchronize access to page/session/application structures. Currently requests are serialized (executed one after another) and each request depends on the fact that when has fired the page state was X. There is even Wicket.ChannelManager in wicket-ajax.js who cares to queue the requests as they arrived. A bigger issue is that when request 1 has finished processing the listener phase, but rendering the response takes too long. What should happen in that instance? How do you imagine to control one thread from another ? Currently the web container worker thread does the whole processing. To be able to interrupt the hanging thread we will need to start our own threads and manage them. Martijn -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: HEADS UP: A change in web.xml setup is required
PersistentPageManager$SessionEntry is the serializable piece of Wicket inside the servlet session, IMO it should serialize/deserialize regardless of the Wicket lifecycle. Can the DefaultPageStore be changed to be a singleton an not a per application instance? On Fri, Mar 18, 2011 at 12:42 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: 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 mgrigo...@apache.org wrote: On Thu, Mar 17, 2011 at 10:54 PM, Martin Grigorov mgrigo...@apache.org 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=13008166page=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/ -- Pedro Henrique Oliveira dos Santos
Re: HEADS UP: A change in web.xml setup is required
even if it were a singleton, some containers will load spooled sessions on startup before the filter is initialized, thus even the singleton would be not yet there. -igor On Fri, Mar 18, 2011 at 11:17 AM, Pedro Santos pedros...@gmail.com wrote: PersistentPageManager$SessionEntry is the serializable piece of Wicket inside the servlet session, IMO it should serialize/deserialize regardless of the Wicket lifecycle. Can the DefaultPageStore be changed to be a singleton an not a per application instance? On Fri, Mar 18, 2011 at 12:42 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: 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 mgrigo...@apache.org wrote: On Thu, Mar 17, 2011 at 10:54 PM, Martin Grigorov mgrigo...@apache.org 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=13008166page=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/ -- Pedro Henrique Oliveira dos Santos
Re: HEADS UP: A change in web.xml setup is required
Heads down :-) Together with Pedro we made another brainstorm session in IRC and we realised how 1.4 works. I'll write it down here for the generations. If Matej still reads here I'd love to hear his confirmation. In short: there is no need to change anything! In details: Wicket stores the page instances in the session in org.apache.wicket.page.PersistentPageManager.SessionEntry object. When the http session has to be replicated or there are more pages in the memory than the configured (see org.apache.wicket.pageStore.DefaultPageStore.SerializedPagesCache.size) then those pages has to be serialized. Case 1) Here if there is Application available (worker thread) then a SerializedPage is created from a Page instance. A SerializedPage is as I said earlier: int pageId; String sessionId; byte[] data; // the page itself pageId and sessionId are used to be able to be able to find later the page in the IDataStore (e.g. DiskDataStore) and cleaned if the session expires from this store. Case 2) There is no Application (WicketFilter#destroy() thread) then the http session is being serialized by the web container so that after restart of the application/container the application can reload its sessions. In this case we don't need the session id for our needs in IDataStore (because it is not used in this case) and we can serialize just the Page instance without the two additional slots. Later when org.apache.wicket.page.PersistentPageManager.SessionEntry.readObject(ObjectInputStream) is called we load just Serializable in an List (org.apache.wicket.page.PersistentPageManager.SessionEntry.afterReadObject). This Serializable can be either Page or SerializedPage. Even later when the first org.apache.wicket.page.PersistentPageManager.SessionEntry.getPage(int) comes (this is always a worker thread, so there is Application available) the entries from this List are passed to org.apache.wicket.pageStore.IPageStore.convertToPage(Object) where they are potentially converted from SerializedPage to Page. That's it. This is how it works in 1.4 too. Just in 1.5 the related classes are either renamed or completely rewritten. The fix is removal of two lines. I tested it with Tomcat7 and wicket-examples - compref - TabbedPanel. Scenario: - start the app. - click randomly on the tabs. - stop the app - start the app - click on any tab Without the fix I get PageExpiredException at the last step and the reported exception in the ticket when stopping the app With the fix there are no exceptions at all and clicking on any tab works just like there was no restart. On Fri, Mar 18, 2011 at 7:19 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: even if it were a singleton, some containers will load spooled sessions on startup before the filter is initialized, thus even the singleton would be not yet there. -igor On Fri, Mar 18, 2011 at 11:17 AM, Pedro Santos pedros...@gmail.com wrote: PersistentPageManager$SessionEntry is the serializable piece of Wicket inside the servlet session, IMO it should serialize/deserialize regardless of the Wicket lifecycle. Can the DefaultPageStore be changed to be a singleton an not a per application instance? On Fri, Mar 18, 2011 at 12:42 PM, Igor Vaynberg igor.vaynb...@gmail.com 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 mgrigo...@apache.org wrote: On Thu, Mar 17, 2011 at 10:54 PM, Martin Grigorov mgrigo...@apache.org 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=13008166page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13008166Idescribeda 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/ -- Pedro Henrique Oliveira dos Santos -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: HEADS UP: A change in web.xml setup is required
r1083061 On Fri, Mar 18, 2011 at 9:49 PM, Martin Grigorov mgrigo...@apache.orgwrote: Heads down :-) Together with Pedro we made another brainstorm session in IRC and we realised how 1.4 works. I'll write it down here for the generations. If Matej still reads here I'd love to hear his confirmation. In short: there is no need to change anything! In details: Wicket stores the page instances in the session in org.apache.wicket.page.PersistentPageManager.SessionEntry object. When the http session has to be replicated or there are more pages in the memory than the configured (see org.apache.wicket.pageStore.DefaultPageStore.SerializedPagesCache.size) then those pages has to be serialized. Case 1) Here if there is Application available (worker thread) then a SerializedPage is created from a Page instance. A SerializedPage is as I said earlier: int pageId; String sessionId; byte[] data; // the page itself pageId and sessionId are used to be able to be able to find later the page in the IDataStore (e.g. DiskDataStore) and cleaned if the session expires from this store. Case 2) There is no Application (WicketFilter#destroy() thread) then the http session is being serialized by the web container so that after restart of the application/container the application can reload its sessions. In this case we don't need the session id for our needs in IDataStore (because it is not used in this case) and we can serialize just the Page instance without the two additional slots. Later when org.apache.wicket.page.PersistentPageManager.SessionEntry.readObject(ObjectInputStream) is called we load just Serializable in an List (org.apache.wicket.page.PersistentPageManager.SessionEntry.afterReadObject). This Serializable can be either Page or SerializedPage. Even later when the first org.apache.wicket.page.PersistentPageManager.SessionEntry.getPage(int) comes (this is always a worker thread, so there is Application available) the entries from this List are passed to org.apache.wicket.pageStore.IPageStore.convertToPage(Object) where they are potentially converted from SerializedPage to Page. That's it. This is how it works in 1.4 too. Just in 1.5 the related classes are either renamed or completely rewritten. The fix is removal of two lines. I tested it with Tomcat7 and wicket-examples - compref - TabbedPanel. Scenario: - start the app. - click randomly on the tabs. - stop the app - start the app - click on any tab Without the fix I get PageExpiredException at the last step and the reported exception in the ticket when stopping the app With the fix there are no exceptions at all and clicking on any tab works just like there was no restart. On Fri, Mar 18, 2011 at 7:19 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: even if it were a singleton, some containers will load spooled sessions on startup before the filter is initialized, thus even the singleton would be not yet there. -igor On Fri, Mar 18, 2011 at 11:17 AM, Pedro Santos pedros...@gmail.com wrote: PersistentPageManager$SessionEntry is the serializable piece of Wicket inside the servlet session, IMO it should serialize/deserialize regardless of the Wicket lifecycle. Can the DefaultPageStore be changed to be a singleton an not a per application instance? On Fri, Mar 18, 2011 at 12:42 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: 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 mgrigo...@apache.org wrote: On Thu, Mar 17, 2011 at 10:54 PM, Martin Grigorov mgrigo...@apache.org 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=13008166page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13008166Idescribeda 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/ -- Pedro Henrique Oliveira dos Santos -- Martin Grigorov jWeekend
