Re: debugging PageExpiredExceptions
Thanks for the reply Martijn. I have done some poking around and I think this thread holds the key: http://apache-wicket.1842946.n4.nabble.com/PageExpiredException-ajax-request-td1878866.html#a1878866 PageExpiredException - ajax request It looks like our 'stateless' page gets rendered with AJAX links in it that get saved to the pagemap. If I open another browser window and interact with the application for a period of time it seems the AJAX link references in the initial tab are removed from the page map so if I click on any of them the app returns a PEE. So it seems the answer is to detect the PEE and then regenerate a fresh version of the page. I am still working on that part but at least I have learned some more about areas of the framework I hadn't spent enough time with to this point. Some questions around ajax, stateless/statefull pages and page mounts. (please forgive me if any of these reflect my ignorance). - if I have a stateless page(mounted page with an empty/PageParameter constructor) but add elements/panels with AJAX behaviors does it become statefull? Confusingly isStateless() always returns true even though the page seems to be referenced in the pagemap. I'm still trying to fully understand the relationship between stateless and statefull in Wicket. - should either of the following have any effect? getRequestCycleSettings().setBufferResponse(false); getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.ONE_PASS_RENDER); - setting setAutomaticMultiWindowSupport to true adds the following to new urls: /wicket:pageMapName/wicket-3/. Is there any way to prevent this as it mangles the URL effect I am trying to implement? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/debugging-PageExpiredExceptions-tp1882040p2277017.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: debugging PageExpiredExceptions
On Thu, Jul 1, 2010 at 2:30 AM, sbrookes2 seanbroo...@shaw.ca wrote: It turns out that isn't the only source of these messages as it seems to be related to using AJAX behaviors on stateless pages causing the pagemap to either lose or remove references to certain pages so that when an AJAX request comes in the requesting URL is no longer valid (if http://apache-wicket.1842946.n4.nabble.com/Using-AbstractDefaultAjaxBehavior-on-a-Bookmarkable-page-td1861596.html I understand the previous thread ) AFAIK wicket ajax is not supported on stateless pages (roll your own solutions might very well work though). Martijn - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: debugging PageExpiredExceptions
ver 1.3.6 I have been tracking this issue for a few months now in our app. Similar to the following threads: http://apache-wicket.1842946.n4.nabble.com/PageExpiredException-getting-this-when-the-session-hasn-t-timeout-td1894202.html#a1894216 PageExpiredException - getting this when the session hasn't timeout http://apache-wicket.1842946.n4.nabble.com/PageExpiredException-on-ajax-calls-if-apps-pages-are-opened-in-different-tabs-td1884182.html#a1884182 PageExpiredException on ajax calls if apps pages are opened in different tabs http://apache-wicket.1842946.n4.nabble.com/Using-AbstractDefaultAjaxBehavior-on-a-Bookmarkable-page-td1861596.html Using AbstractDefaultAjaxBehavior on a Bookmarkable page? Our design goal is a simple RESTful page navigation with moderate AJAX interactions on the pages (join/leave groups, rate items, connect to people, etc). If a user refreshes the page or clicks the back button we simply repaint the page using whatever state the spring beans return. We are using IndexedParamUrlCodingStrategy and have implemented a relatively simple navigation infrastructure using simple href/get requests with manually generated links eg: http://server/web/common/profilehome/userxyz Where 'common' is the mount name and userxyz is parameter 0. So far so good. The pages are stateless and automaticWindowSupport = false (we can't have the additional parameters on our URL) I have been seeing these exceptions for a while : - Cannot find the rendered page in session - The target page does not exist anymore I thought the issue was limited to a cached page not matching the current state so I implemented a temporary hack in order to improve the user experience (it was getting very common) by intercepting the PEE and redirecting to the current request URL (i.e. trigger a page refresh) which really calmed things down from a user experience perspective but the messages kept coming in. It turns out that isn't the only source of these messages as it seems to be related to using AJAX behaviors on stateless pages causing the pagemap to either lose or remove references to certain pages so that when an AJAX request comes in the requesting URL is no longer valid (if http://apache-wicket.1842946.n4.nabble.com/Using-AbstractDefaultAjaxBehavior-on-a-Bookmarkable-page-td1861596.html I understand the previous thread ) I see a few possible paths forward and would like to get some feedback from the community on them and to see if there is additional information you can share to help me out here. 1) I looked at the technique in this blog post: http://day-to-day-stuff.blogspot.com/2008/10/wicket-extreme-consistent-urls.html Wicket extreme consistent URLs and it looks like it may be a possibility but unfortunately we are using indexed parameters and the technique is based on named parameters so it would mean quite a bit of work to rework our navigation implementation so I am reluctant to venture to far down that path until it is either confirmed by someone here or we run out of other options 2) Is there some setting or pagemap configuration that I don't know about that would either keep the pages in the store or 'turn off' the page map altogether? 3) Convert our AJAX calls from wicket based to a more generic 'servlet' style so that we would construct the AJAX target URL ourselves to remove the dependency on the native wicket url and hopefully bypass the pagemap reference altogether. Would this 'solve' the problem? It would also be quite a lot of work but we have been moving in this direction for a while now anyway in order to get more control over our AJAX for performance reasons so if this sounds like a viable way to avoid the PEEs then at least we would be able to commit to it and get on with fixing it. Wicket has been very good to us for a couple of years but now that I am trying to implement a 'real' fix I am concerned I may have made a big architecture mistake given the heavy emphasis on state with Wicket. Hopefully there is a magic bullet out there someone can share. Thanks, Sean -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/debugging-PageExpiredExceptions-tp1882040p2274494.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: debugging PageExpiredExceptions
So far I traced this down to the fact that sometimes some wicket:interface requests (in our case used in img src and in anchor 'href) do not include a jsessionid - either as a ;jsessionid= URL param or a cookie - thus no session can be found. The container's impl of HttpServletResponse.encodeURL(String) decides whether to rewrite the URL with jsessionid. It's supposed to NOT rewrite the URL if the client is confirmed to support cookie (though there are other criteria). I imagine that works correctly (we're using Tomcat 6.0.20). Anyone know of cases wherein wicket does not call response.encodeURL(generatedURL) for whatever reason? -nikita On Fri, Apr 9, 2010 at 3:51 PM, Nikita Tovstoles nikita.tovsto...@gmail.com wrote: Here's a typical exception: 00:01:17,644 ERROR CLPWebRequestCycle:34 - Cannot find the rendered page in session [pagemap=null,componentPath=7:results:resultsInfo:criteriaContainer:inputPanel:categorySearchForm:submitLink:searchButton,versionNumber=0] org.apache.wicket.protocol.http.PageExpiredException: Cannot find the rendered page in session [pagemap=null,componentPath=7:results:resultsInfo:criteriaContainer:inputPanel:categorySearchForm:submitLink:searchButton,versionNumber=0] at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:197) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1310) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428) at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312) On Fri, Apr 9, 2010 at 3:35 PM, Nikita Tovstoles nikita.tovsto...@gmail.com wrote: We're seeing a PageExpiredExceptions in roughly 2-6% of our production web sessions and cannot determine the root cause: 1. it's not a session affinity problem (we went as far as running a single node - the exceptions persisted) 2. it's not a session expiration case (our avg production session is far less than 40 min session timeout value; given the number of sessions wherein PEEs occur it's highly unlikely that those sessions are the 40+ min outliers 3. it's not a serialization problem - everything on pages is serializable. And if it were a serialization issue, should we not be seeing WicketSerializeableException stack traces in the logs? 4. Settings.automaticMultiWindowSupport remains at default (=true) 5. we cannot come up with a consistent repro though somehow managed to cause PEE to happen a couple of times by seemingly randomly clicking on UI controls and playing with back/forward browser buttons Any tips on how to go about determining the root cause? Looking at the exception below (typical - always thrown from WebRequestCycleProcessor.resolve()), what specifically would you look for? Which loggers would it be useful to turn to debug? Also, is there any way to determine Page class type when catching a PageExpiredException - so at least we could implement on PEE throw new RestartResponseException(pageType, defaultParams) - instead of showing the default error page. thanks, -nikita
Re: debugging PageExpiredExceptions
We're interested in this as well, as our logs are full of these as well. On Mon, Apr 12, 2010 at 10:32 AM, Nikita Tovstoles nikita.tovsto...@gmail.com wrote: So far I traced this down to the fact that sometimes some wicket:interface requests (in our case used in img src and in anchor 'href) do not include a jsessionid - either as a ;jsessionid= URL param or a cookie - thus no session can be found. The container's impl of HttpServletResponse.encodeURL(String) decides whether to rewrite the URL with jsessionid. It's supposed to NOT rewrite the URL if the client is confirmed to support cookie (though there are other criteria). I imagine that works correctly (we're using Tomcat 6.0.20). Anyone know of cases wherein wicket does not call response.encodeURL(generatedURL) for whatever reason? -nikita On Fri, Apr 9, 2010 at 3:51 PM, Nikita Tovstoles nikita.tovsto...@gmail.com wrote: Here's a typical exception: 00:01:17,644 ERROR CLPWebRequestCycle:34 - Cannot find the rendered page in session [pagemap=null,componentPath=7:results:resultsInfo:criteriaContainer:inputPanel:categorySearchForm:submitLink:searchButton,versionNumber=0] org.apache.wicket.protocol.http.PageExpiredException: Cannot find the rendered page in session [pagemap=null,componentPath=7:results:resultsInfo:criteriaContainer:inputPanel:categorySearchForm:submitLink:searchButton,versionNumber=0] at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:197) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1310) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428) at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312) On Fri, Apr 9, 2010 at 3:35 PM, Nikita Tovstoles nikita.tovsto...@gmail.com wrote: We're seeing a PageExpiredExceptions in roughly 2-6% of our production web sessions and cannot determine the root cause: 1. it's not a session affinity problem (we went as far as running a single node - the exceptions persisted) 2. it's not a session expiration case (our avg production session is far less than 40 min session timeout value; given the number of sessions wherein PEEs occur it's highly unlikely that those sessions are the 40+ min outliers 3. it's not a serialization problem - everything on pages is serializable. And if it were a serialization issue, should we not be seeing WicketSerializeableException stack traces in the logs? 4. Settings.automaticMultiWindowSupport remains at default (=true) 5. we cannot come up with a consistent repro though somehow managed to cause PEE to happen a couple of times by seemingly randomly clicking on UI controls and playing with back/forward browser buttons Any tips on how to go about determining the root cause? Looking at the exception below (typical - always thrown from WebRequestCycleProcessor.resolve()), what specifically would you look for? Which loggers would it be useful to turn to debug? Also, is there any way to determine Page class type when catching a PageExpiredException - so at least we could implement on PEE throw new RestartResponseException(pageType, defaultParams) - instead of showing the default error page. thanks, -nikita - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: debugging PageExpiredExceptions
Here's a typical exception: 00:01:17,644 ERROR CLPWebRequestCycle:34 - Cannot find the rendered page in session [pagemap=null,componentPath=7:results:resultsInfo:criteriaContainer:inputPanel:categorySearchForm:submitLink:searchButton,versionNumber=0] org.apache.wicket.protocol.http.PageExpiredException: Cannot find the rendered page in session [pagemap=null,componentPath=7:results:resultsInfo:criteriaContainer:inputPanel:categorySearchForm:submitLink:searchButton,versionNumber=0] at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:197) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1310) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428) at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312) On Fri, Apr 9, 2010 at 3:35 PM, Nikita Tovstoles nikita.tovsto...@gmail.com wrote: We're seeing a PageExpiredExceptions in roughly 2-6% of our production web sessions and cannot determine the root cause: 1. it's not a session affinity problem (we went as far as running a single node - the exceptions persisted) 2. it's not a session expiration case (our avg production session is far less than 40 min session timeout value; given the number of sessions wherein PEEs occur it's highly unlikely that those sessions are the 40+ min outliers 3. it's not a serialization problem - everything on pages is serializable. And if it were a serialization issue, should we not be seeing WicketSerializeableException stack traces in the logs? 4. Settings.automaticMultiWindowSupport remains at default (=true) 5. we cannot come up with a consistent repro though somehow managed to cause PEE to happen a couple of times by seemingly randomly clicking on UI controls and playing with back/forward browser buttons Any tips on how to go about determining the root cause? Looking at the exception below (typical - always thrown from WebRequestCycleProcessor.resolve()), what specifically would you look for? Which loggers would it be useful to turn to debug? Also, is there any way to determine Page class type when catching a PageExpiredException - so at least we could implement on PEE throw new RestartResponseException(pageType, defaultParams) - instead of showing the default error page. thanks, -nikita
