The last page is kept in the session such that it is transferred across the cluster. Each node in the cluster should then update the local pagestore with that page. Matej has written quite a bit about this behavior on this list, so searching might help.
Martijn On Wed, Mar 31, 2010 at 5:02 PM, Richard Wilkinson <richardjohnwilkin...@googlemail.com> wrote: > afaik, the default SecondLevelCacheSessionStore works by keeping the current > page in session (in memory) and uses DiskPageStore as its second level > cache, which stores all the other pages in a file on disk. > > I don't believe that this DiskPageStore is clustered, because it is an > actual file on the machine. If this is the case then although the current > page will be clustered by tomcat, the previous pages wont be, so wont be > available on the other machine. This could cause the exception you are > seeing. > > However that is about the limit of my knowledge on the subject, and maybe > now the DiskPageStore is clusterable. When I have done clustering in the > past I used a custom session store. > > Also I remember reading that you have to tell tomcat not to keep session > attributes serialized after replication for it to work correctly see [1], > (although that is a few years old) > > [1] - http://old.nabble.com/A-few-clustering-questions-td16993201.html > > -- > > Regards - Richard Wilkinson > Developer, > jWeekend: OO & Java Technologies - Development and Training > http://jWeekend.com > > On 31 March 2010 15:40, Wayne Pope <waynemailingli...@googlemail.com> wrote: > >> Thanks for the explanation Richard. >> >> We do have setAutomaticMultiWindowSupport set to false, because when >> we had it set to true we had some problems (I cannot remember what >> exactly - something to do with url mounting I think). >> >> Thing is when I experienced this issue I only had one tab open - it >> may explain some of the other similar exceptions in the log though. >> We're using the default SecondLevelCacheSessionStore. >> >> the plot thickens! >> >> >> On Wed, Mar 31, 2010 at 4:22 PM, Richard Wilkinson >> <richardjohnwilkin...@googlemail.com> wrote: >> > 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 >> >> >> >> >> > >> >> --------------------------------------------------------------------- >> 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
