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
