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 >> >
