Hi, Ok, anyone else please correct me if i am wrong, but afaik:
The pagemap holds a finite number of pages in it, each time you access a new page it gets added to the page map, how many pages it holds depends on which implementation of page map you are using, which usually depends on which type of session store you are using, but usually pages are evicted from the page map on a least recently used basis. If you had 2 tabs open, did a load of stuff on one tab, then went back to the other, it is quite possible the page in the other tab will have been removed from the page map. However wicket should by default try and detect that a new tab is open, and give the other tab a different page map, but this is not completely reliable. Also this can be turned off (application.getPageSettings().setAutomaticMultiWindowSupport(false); i think), which maybe you have done. -- Regards - Richard Wilkinson Developer, jWeekend: OO & Java Technologies - Development and Training http://jWeekend.com On 31 March 2010 15:02, Wayne Pope <waynemailingli...@googlemail.com> wrote: > Hi Richard, > > thanks for the reply. > I'll have a look at trying to make the failover fail again - but the > last time we tested it was working fine so unless there is a core > problem with the apache balancer and tomcat I don't know what I can > do. > > > > There are probably other reasons why you might see a page expired > exception, > > for example if you access so many pages after the page you get the > exception > > on that it is it pushed out of the page map, but unless you can reproduce > it > > by going directly a single tomcat instance, it is probably down to the > > clustering. > > Problem is I cannot reproduce it at all (and I have tried for quite > some time now). Can you explain a little more: > > >if you access so many pages after the page you get the exception > > on that it is it pushed out of the page map, > > Do you mean if we have 2 tabs open , and on one I move around the > pages then go back to the first tab and try and do something? > > > > > On Wed, Mar 31, 2010 at 3:26 PM, Richard Wilkinson > <richardjohnwilkin...@googlemail.com> wrote: > > Ok, > > > > If you can replicate the problem by the following: > > 1) shutting down tomcat 1, therefore ensuring that you go to tomcat 2, > > 2) going to a page on your site (that has some ajax on there), > > 3) starting up tomcat 1, then shutting down tomcat 2, therefore ensuring > > that the next request goes to tomcat 1, > > 4) then make an ajax request on the current page. > > > > If you see the page expired then, it probably indicates that your tomcat > > session clustering is either is not working correctly, or that > > you don't have any clustering in place. Either of these problems will > mean > > that sessions are not shared to the other tomcat. So whenever apache > > decides not to obey the sticky sessions (which it can do if it cannot > access > > the tomcat it wants to access) your users session (and pagemap) will not > > be accessible, so you will see the page expired exception. > > > > You can also replicate this by making apache do 'round robin' clustering > > since then you are pretty sure that requests will be fired > > to different boxes. > > > > If this is the problem, it will affect all users using your site at the > time > > (ie they will all experience the exception), so you may want to try and > test > > away from production if this is a problem for you. > > > > There are probably other reasons why you might see a page expired > exception, > > for example if you access so many pages after the page you get the > exception > > on that it is it pushed out of the page map, but unless you can reproduce > it > > by going directly a single tomcat instance, it is probably down to the > > clustering. > > > > Hope that helps. > > > > -- > > Regards - Richard Wilkinson > > Developer, > > jWeekend: OO & Java Technologies - Development and Training > > http://jWeekend.com > > > > > > > > > > On 31 March 2010 14:04, Wayne Pope <waynemailingli...@googlemail.com> > wrote: > > > >> Hi Richard > >> > >> my mistake we have the following setting: > >> > >> ProxyPass / balancer://cluster/ stickysession=JSESSIONID nofailover=Off > >> > >> This problem happens from time to time in production with no pattern > >> that we can find. We have a 'shared' firewall that hosts the SSL cert, > >> going to the apache instance which balances to 2 tomcat instances. > >> > >> I know its happening as I've experienced it myself but there seems no > >> reason for it. We're using cookie sessions rather than url > >> > >> > >> > >> > >> On Wed, Mar 31, 2010 at 2:51 PM, Richard Wilkinson > >> <richardjohnwilkin...@googlemail.com> wrote: > >> > Hi Wayne, > >> > > >> > As far as I know mod_proxy_balancer does not have sticky sessions on > by > >> > default, you have to tell it what cookie to use. Am am assuming that > you > >> > have multiple tomcats (or similar) behind apache, are you using any > sort > >> of > >> > session replication for them? > >> > > >> > Does this exception occur when you go directly to tomcat (or whatever > you > >> > are using) and bypass apache, if so then it indicates a different > >> problem. > >> > > >> > -- > >> > Regards - Richard Wilkinson > >> > Developer, > >> > jWeekend: OO & Java Technologies - Development and Training > >> > http://jWeekend.com > >> > > >> > On 31 March 2010 13:28, Wayne Pope <waynemailingli...@googlemail.com> > >> wrote: > >> > > >> >> Well as far as I know the default balancer in apache supports this > yes. > >> >> > >> >> > >> >> > >> >> On Mon, Mar 29, 2010 at 2:22 PM, Martijn Dashorst > >> >> <martijn.dasho...@gmail.com> wrote: > >> >> > Are you using sticky sessions? > >> >> > > >> >> > Martijn > >> >> > > >> >> > On Fri, Mar 26, 2010 at 5:15 PM, Wayne Pope > >> >> > <waynemailingli...@googlemail.com> wrote: > >> >> >> One more bit of info - it was a ajax request that caused this. > >> >> >> > >> >> >> Any ideas? > >> >> >> > >> >> >> > >> >> >> On Fri, Mar 26, 2010 at 3:42 PM, Wayne Pope < > >> >> waynemailingli...@gmail.com> wrote: > >> >> >>> > >> >> >>> > >> >> >>> oh and I doubled check that all the classes implement > Serializable > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> Wayne Pope-2 wrote: > >> >> >>>> > >> >> >>>> Hi, > >> >> >>>> > >> >> >>>> we're getting this exception in production sometimes, and today > I > >> >> >>>> experienced it first hand. > >> >> >>>> We have a session of 60 mins set in the web.xml - however I got > >> this > >> >> >>>> after just 5 mins: > >> >> >>>> > >> >> >>>> org.apache.wicket.protocol.http.PageExpiredException: Cannot > find > >> the > >> >> >>>> rendered page in session > >> >> >>>> [pagemap=null,componentPath=1,versionNumber=0] > >> >> >>>> at > >> >> >>>> > >> >> > >> > org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:197) > >> >> >>>> at > >> >> >>>> > >> >> > >> > hub.app.wicket.app.HubRequestCycleProcessor.resolve(HubRequestCycleProcessor.java:137) > >> >> >>>> at > >> org.apache.wicket.RequestCycle.step(RequestCycle.java:1301) > >> >> >>>> at > >> >> org.apache.wicket.RequestCycle.steps(RequestCycle.java:1419) > >> >> >>>> at > >> >> org.apache.wicket.RequestCycle.request(RequestCycle.java:545) > >> >> >>>> at > >> >> >>>> > >> >> > >> > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:456) > >> >> >>>> at > >> >> >>>> > >> >> > >> > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:289) > >> >> >>>> at > >> >> >>>> > >> >> > >> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > >> >> >>>> at > >> >> >>>> > >> >> > >> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > >> >> >>>> at > >> >> >>>> > >> >> > >> > com.wideplay.warp.persist.PersistenceFilter$3.run(PersistenceFilter.java:141) > >> >> >>>> at > >> >> >>>> > >> >> > >> > com.wideplay.warp.persist.internal.Lifecycles.failEarlyAndLeaveNoOneBehind(Lifecycles.java:29) > >> >> >>>> at > >> >> >>>> > >> >> > >> > com.wideplay.warp.persist.PersistenceFilter.doFilter(PersistenceFilter.java:155) > >> >> >>>> at > >> >> >>>> > >> >> > >> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > >> >> >>>> at > >> >> >>>> > >> >> > >> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > >> >> >>>> at > >> >> >>>> > >> >> > >> > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > >> >> >>>> at > >> >> >>>> > >> >> > >> > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > >> >> >>>> at > >> >> >>>> > >> >> > >> > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > >> >> >>>> at > >> >> >>>> > >> >> > >> > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > >> >> >>>> at > >> >> >>>> > >> >> > >> > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > >> >> >>>> at > >> >> >>>> > >> >> > >> > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) > >> >> >>>> at > >> >> >>>> > >> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) > >> >> >>>> at > >> >> >>>> > org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) > >> >> >>>> at > >> >> >>>> > org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769) > >> >> >>>> at > >> >> >>>> > >> >> > >> > org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:698) > >> >> >>>> at > >> >> >>>> > >> >> > >> > org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:891) > >> >> >>>> at > >> >> >>>> > >> >> > >> > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) > >> >> >>>> at java.lang.Thread.run(Thread.java:619) > >> >> >>>> > >> >> >>>> > >> >> >>>> I honestly don't know where this is coming from. > >> >> >>>> What can cause this? cookie not being passed? apache proxy > balancer > >> >> not > >> >> >>>> working? > >> >> >>>> > >> >> >>>> Has anyone experienced this? > >> >> >>>> > >> >> >>>> > >> >> >>>> PS HubRequestCycleProcessor is just calling > >> WebRequestCycleProcessor > >> >> >>>> > >> >> >>>> > >> --------------------------------------------------------------------- > >> >> >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> >> >>>> For additional commands, e-mail: users-h...@wicket.apache.org > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>> > >> >> >>> -- > >> >> >>> View this message in context: > >> >> > >> > http://old.nabble.com/PageExpiredException---getting-this-when-the-session-hasn%27t-timeout-tp28043403p28043436.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 > >> >> >>> > >> >> >>> > >> >> >> > >> >> >> > --------------------------------------------------------------------- > >> >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> >> >> For additional commands, e-mail: users-h...@wicket.apache.org > >> >> >> > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > Become a Wicket expert, learn from the best: > >> http://wicketinaction.com > >> >> > Apache Wicket 1.4 increases type safety for web applications > >> >> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4 > >> >> > > >> >> > > --------------------------------------------------------------------- > >> >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> >> > For additional commands, e-mail: users-h...@wicket.apache.org > >> >> > > >> >> > > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> >> For additional commands, e-mail: users-h...@wicket.apache.org > >> >> > >> >> > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
