You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Wayne Pope <wa...@googlemail.com> on 2010/03/26 16:15:32 UTC
Re: PageExpiredException - getting this when the session hasn't
timeout
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 <wa...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: PageExpiredException - getting this when the session hasn't
timeout
Posted by Wayne Pope <wa...@googlemail.com>.
Actually - to be clear - we have 2 tomcat instances on the same
machine, but I don't see this being the issue.
So back to the drawing board again :-(
On Wed, Mar 31, 2010 at 6:27 PM, Richard Wilkinson
<ri...@googlemail.com> wrote:
> OK, so so long as all cluster machines are running, they will all have the
> same contents in their DiskPageMap, and you should never see the exception,
> however, if one machine goes down for a bit, any pages visited during that
> time will not be transferred to it when it comes back up, meaning that the
> DiskPageMaps can get out of sync.
>
> --
>
> Regards - Richard Wilkinson
> Developer,
> jWeekend: OO & Java Technologies - Development and Training
> http://jWeekend.com
>
> On 31 March 2010 16:14, Martijn Dashorst <ma...@gmail.com> wrote:
>
>> 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
>> <ri...@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 <wa...@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
>> >> <ri...@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 <wa...@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
>> >> >> <ri...@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 <
>> waynemailinglists@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
>> >> >> >> <ri...@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 <
>> >> waynemailinglists@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
>> >> >> >> >> <ma...@gmail.com> wrote:
>> >> >> >> >> > Are you using sticky sessions?
>> >> >> >> >> >
>> >> >> >> >> > Martijn
>> >> >> >> >> >
>> >> >> >> >> > On Fri, Mar 26, 2010 at 5:15 PM, Wayne Pope
>> >> >> >> >> > <wa...@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 <
>> >> >> >> >> waynemailinglists@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-unsubscribe@wicket.apache.org
>> >> >> >> >> >>>> For additional commands, e-mail:
>> >> users-help@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-unsubscribe@wicket.apache.org
>> >> >> >> >> >>> For additional commands, e-mail:
>> users-help@wicket.apache.org
>> >> >> >> >> >>>
>> >> >> >> >> >>>
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> >> >> For additional commands, e-mail:
>> users-help@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-unsubscribe@wicket.apache.org
>> >> >> >> >> > For additional commands, e-mail:
>> users-help@wicket.apache.org
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: PageExpiredException - getting this when the session hasn't
timeout
Posted by Richard Wilkinson <ri...@googlemail.com>.
OK, so so long as all cluster machines are running, they will all have the
same contents in their DiskPageMap, and you should never see the exception,
however, if one machine goes down for a bit, any pages visited during that
time will not be transferred to it when it comes back up, meaning that the
DiskPageMaps can get out of sync.
--
Regards - Richard Wilkinson
Developer,
jWeekend: OO & Java Technologies - Development and Training
http://jWeekend.com
On 31 March 2010 16:14, Martijn Dashorst <ma...@gmail.com> wrote:
> 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
> <ri...@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 <wa...@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
> >> <ri...@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 <wa...@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
> >> >> <ri...@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 <
> waynemailinglists@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
> >> >> >> <ri...@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 <
> >> waynemailinglists@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
> >> >> >> >> <ma...@gmail.com> wrote:
> >> >> >> >> > Are you using sticky sessions?
> >> >> >> >> >
> >> >> >> >> > Martijn
> >> >> >> >> >
> >> >> >> >> > On Fri, Mar 26, 2010 at 5:15 PM, Wayne Pope
> >> >> >> >> > <wa...@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 <
> >> >> >> >> waynemailinglists@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-unsubscribe@wicket.apache.org
> >> >> >> >> >>>> For additional commands, e-mail:
> >> users-help@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-unsubscribe@wicket.apache.org
> >> >> >> >> >>> For additional commands, e-mail:
> users-help@wicket.apache.org
> >> >> >> >> >>>
> >> >> >> >> >>>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> >> For additional commands, e-mail:
> users-help@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-unsubscribe@wicket.apache.org
> >> >> >> >> > For additional commands, e-mail:
> users-help@wicket.apache.org
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >>
> >> >> >>
> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: PageExpiredException - getting this when the session hasn't
timeout
Posted by Martijn Dashorst <ma...@gmail.com>.
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
<ri...@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 <wa...@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
>> <ri...@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 <wa...@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
>> >> <ri...@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 <wa...@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
>> >> >> <ri...@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 <
>> waynemailinglists@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
>> >> >> >> <ma...@gmail.com> wrote:
>> >> >> >> > Are you using sticky sessions?
>> >> >> >> >
>> >> >> >> > Martijn
>> >> >> >> >
>> >> >> >> > On Fri, Mar 26, 2010 at 5:15 PM, Wayne Pope
>> >> >> >> > <wa...@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 <
>> >> >> >> waynemailinglists@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-unsubscribe@wicket.apache.org
>> >> >> >> >>>> For additional commands, e-mail:
>> users-help@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-unsubscribe@wicket.apache.org
>> >> >> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> >> >>
>> >> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> >> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>> >> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: PageExpiredException - getting this when the session hasn't
timeout
Posted by Wayne Pope <wa...@googlemail.com>.
> 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
<ri...@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 <wa...@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
>> <ri...@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 <wa...@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
>> >> <ri...@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 <wa...@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
>> >> >> <ri...@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 <
>> waynemailinglists@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
>> >> >> >> <ma...@gmail.com> wrote:
>> >> >> >> > Are you using sticky sessions?
>> >> >> >> >
>> >> >> >> > Martijn
>> >> >> >> >
>> >> >> >> > On Fri, Mar 26, 2010 at 5:15 PM, Wayne Pope
>> >> >> >> > <wa...@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 <
>> >> >> >> waynemailinglists@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-unsubscribe@wicket.apache.org
>> >> >> >> >>>> For additional commands, e-mail:
>> users-help@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-unsubscribe@wicket.apache.org
>> >> >> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> >> >>
>> >> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> >> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>> >> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: PageExpiredException - getting this when the session hasn't
timeout
Posted by Richard Wilkinson <ri...@googlemail.com>.
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 <wa...@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
> <ri...@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 <wa...@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
> >> <ri...@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 <wa...@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
> >> >> <ri...@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 <
> waynemailinglists@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
> >> >> >> <ma...@gmail.com> wrote:
> >> >> >> > Are you using sticky sessions?
> >> >> >> >
> >> >> >> > Martijn
> >> >> >> >
> >> >> >> > On Fri, Mar 26, 2010 at 5:15 PM, Wayne Pope
> >> >> >> > <wa...@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 <
> >> >> >> waynemailinglists@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-unsubscribe@wicket.apache.org
> >> >> >> >>>> For additional commands, e-mail:
> users-help@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-unsubscribe@wicket.apache.org
> >> >> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>
> >> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
> >> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: PageExpiredException - getting this when the session hasn't
timeout
Posted by Wayne Pope <wa...@googlemail.com>.
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
<ri...@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 <wa...@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
>> <ri...@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 <wa...@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
>> >> <ri...@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 <wa...@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
>> >> >> <ma...@gmail.com> wrote:
>> >> >> > Are you using sticky sessions?
>> >> >> >
>> >> >> > Martijn
>> >> >> >
>> >> >> > On Fri, Mar 26, 2010 at 5:15 PM, Wayne Pope
>> >> >> > <wa...@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 <
>> >> >> waynemailinglists@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-unsubscribe@wicket.apache.org
>> >> >> >>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>> >> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>>
>> >> >> >>>
>> >> >> >>
>> >> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: PageExpiredException - getting this when the session hasn't
timeout
Posted by Richard Wilkinson <ri...@googlemail.com>.
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 <wa...@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
> <ri...@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 <wa...@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
> >> <ri...@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 <wa...@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
> >> >> <ma...@gmail.com> wrote:
> >> >> > Are you using sticky sessions?
> >> >> >
> >> >> > Martijn
> >> >> >
> >> >> > On Fri, Mar 26, 2010 at 5:15 PM, Wayne Pope
> >> >> > <wa...@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 <
> >> >> waynemailinglists@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-unsubscribe@wicket.apache.org
> >> >> >>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
> >> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >>
> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: PageExpiredException - getting this when the session hasn't
timeout
Posted by Wayne Pope <wa...@googlemail.com>.
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
<ri...@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 <wa...@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
>> <ri...@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 <wa...@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
>> >> <ma...@gmail.com> wrote:
>> >> > Are you using sticky sessions?
>> >> >
>> >> > Martijn
>> >> >
>> >> > On Fri, Mar 26, 2010 at 5:15 PM, Wayne Pope
>> >> > <wa...@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 <
>> >> waynemailinglists@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-unsubscribe@wicket.apache.org
>> >> >>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>>
>> >> >>>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: PageExpiredException - getting this when the session hasn't
timeout
Posted by Richard Wilkinson <ri...@googlemail.com>.
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 <wa...@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
> <ri...@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 <wa...@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
> >> <ma...@gmail.com> wrote:
> >> > Are you using sticky sessions?
> >> >
> >> > Martijn
> >> >
> >> > On Fri, Mar 26, 2010 at 5:15 PM, Wayne Pope
> >> > <wa...@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 <
> >> waynemailinglists@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-unsubscribe@wicket.apache.org
> >> >>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: PageExpiredException - getting this when the session hasn't
timeout
Posted by Wayne Pope <wa...@googlemail.com>.
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
<ri...@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 <wa...@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
>> <ma...@gmail.com> wrote:
>> > Are you using sticky sessions?
>> >
>> > Martijn
>> >
>> > On Fri, Mar 26, 2010 at 5:15 PM, Wayne Pope
>> > <wa...@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 <
>> waynemailinglists@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-unsubscribe@wicket.apache.org
>> >>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: PageExpiredException - getting this when the session hasn't
timeout
Posted by Richard Wilkinson <ri...@googlemail.com>.
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 <wa...@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
> <ma...@gmail.com> wrote:
> > Are you using sticky sessions?
> >
> > Martijn
> >
> > On Fri, Mar 26, 2010 at 5:15 PM, Wayne Pope
> > <wa...@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 <
> waynemailinglists@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-unsubscribe@wicket.apache.org
> >>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: PageExpiredException - getting this when the session hasn't
timeout
Posted by Wayne Pope <wa...@googlemail.com>.
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
<ma...@gmail.com> wrote:
> Are you using sticky sessions?
>
> Martijn
>
> On Fri, Mar 26, 2010 at 5:15 PM, Wayne Pope
> <wa...@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 <wa...@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-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: PageExpiredException - getting this when the session hasn't
timeout
Posted by Martijn Dashorst <ma...@gmail.com>.
Are you using sticky sessions?
Martijn
On Fri, Mar 26, 2010 at 5:15 PM, Wayne Pope
<wa...@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 <wa...@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-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org