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