> 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.
Thanks Richard that was REALLY helpful - I think this could well be the issue - I had no idea about this and now I think about it I'm kicking myself. I have a look into this to try and understand it and do some searches 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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
