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
