Re: Bunch of Page Expired exceptions in Wicket 6.10.0
Yes, but in my example, I was referring to how 2 different apps with different cookies are both running on localhost with different ports. I get this issue all the time on chromium when I test multiple apps all on location with different ports. I keep having to login whenever I refresh a different tab. (yeah, i know it took me 4 months to get back to this but i was busy. :-) ) -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Bunch-of-Page-Expired-exceptions-in-Wicket-6-10-0-tp4661502p4663946.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
Yes, the 60 secs default on GF threw me off over the weekend when I rushed my tests. Is working fine, thanks Martin! ~ Paul -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Monday, September 30, 2013 6:43 AM To: users@wicket.apache.org Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4) https://issues.apache.org/jira/browse/WICKET-5380 On Mon, Sep 30, 2013 at 12:32 PM, Martin Grigorov wrote: > Applying only the first change that I suggested works on all - Jetty > 8, Tomcat 7 and Glassfish 4. > > I've used: > WebRequest webRequest = (WebRequest) RequestCycle.get().getRequest(); > HttpServletRequest httpRequest = > (HttpServletRequest)webRequest.getContainerRequest(); > httpRequest.getSession().setMaxInactiveInterval(10); > > and the session expires according to the web container's configurations. > Jetty's Scavenger thread runs every 30 secs by default, so the session > is invalidated between 1-30 secs after its expiration time. > Tomcat and GF seems to do this every 60 secs by default. > > I'll create a ticket and commit the change. > > > On Mon, Sep 30, 2013 at 11:55 AM, Martin Grigorov wrote: > >> Tomcat 7.x makes identity check: >> >> org.apache.catalina.session.StandardSession#setAttribute >> // Call the valueUnbound() method if necessary >> if (notify && (unbound != null) && (unbound != value) && >> (unbound instanceof HttpSessionBindingListener)) { >> >> >> On Mon, Sep 30, 2013 at 11:49 AM, Martin Grigorov >> wrote: >> >>> Jetty 8.1.13 checks for equality of the old and the new values: >>> org.eclipse.jetty.server.session.AbstractSession#setAttribute >>> public void setAttribute(String name, Object value) >>> { >>> Object old=null; >>> synchronized (this) >>> { >>> checkValid(); >>> old=doPutOrRemove(name,value); >>> } >>> >>> if (value==null || !value.equals(old)) // <<<<< >>> { >>> if (old!=null) >>> unbindValue(name,old); >>> >>> Since SessionEntry doesn't override #equals() the check is by reference. >>> Thus no notification. >>> >>> >>> >>> On Mon, Sep 30, 2013 at 11:32 AM, Martin Grigorov >>> wrote: >>> >>>> I'll test this and let you know. >>>> >>>> >>>> On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors wrote: >>>> >>>>> Sorry for the delay, it's the weekend :) >>>>> >>>>> In our webapp we let the system administrator control the user >>>>> session timeout which we set it via the Login page as: >>>>> WebRequest webRequest = >>>>> (WebRequest)RequestCycle.get().getRequest(); >>>>> HttpServletRequest httpRequest = >>>>> (HttpServletRequest)webRequest.getContainerRequest(); >>>>> httpRequest.getSession().setMaxInactiveInterval(sessionDuration); >>>>> >>>>> I set the session duration to 1 min and tried it with the new >>>>> implementation for the getSessionEntry(), waited for a good 2-3 >>>>> mins and the session is never invalidated any longer as if it's no longer >>>>> touched. >>>>> My breakpoint on SessionEntry.valueUnbound() is not called either, >>>>> unless explicitly through the Logout button which calls >>>>> o.a.w.protocol.http.WebSession.get().invalidateNow(); >>>>> >>>>> This is what makes me think that going off the HttpSessionListener >>>>> might be better. >>>>> >>>>> ~ Thank you, >>>>> Paul Bors >>>>> >>>>> -Original Message- >>>>> From: Martin Grigorov [mailto:mgrigo...@apache.org] >>>>> Sent: Saturday, September 28, 2013 3:44 AM >>>>> To: users@wicket.apache.org >>>>> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 >>>>> (GlassFish v3 and v4) >>>>> >>>>> I think both suggestions should be applied. >>>>> The intentions are more clear, IMO. >>>>> >>>>> But let's wait Paul to explain what problem he faced. I don't >>>>> expect problems with session timeouts because this is managed by >>>>> the web container. If there
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
https://issues.apache.org/jira/browse/WICKET-5380 On Mon, Sep 30, 2013 at 12:32 PM, Martin Grigorov wrote: > Applying only the first change that I suggested works on all - Jetty 8, > Tomcat 7 and Glassfish 4. > > I've used: > WebRequest webRequest = (WebRequest) RequestCycle.get().getRequest(); > HttpServletRequest httpRequest = > (HttpServletRequest)webRequest.getContainerRequest(); > httpRequest.getSession().setMaxInactiveInterval(10); > > and the session expires according to the web container's configurations. > Jetty's Scavenger thread runs every 30 secs by default, so the session is > invalidated between 1-30 secs after its expiration time. > Tomcat and GF seems to do this every 60 secs by default. > > I'll create a ticket and commit the change. > > > On Mon, Sep 30, 2013 at 11:55 AM, Martin Grigorov wrote: > >> Tomcat 7.x makes identity check: >> >> org.apache.catalina.session.StandardSession#setAttribute >> // Call the valueUnbound() method if necessary >> if (notify && (unbound != null) && (unbound != value) && >> (unbound instanceof HttpSessionBindingListener)) { >> >> >> On Mon, Sep 30, 2013 at 11:49 AM, Martin Grigorov >> wrote: >> >>> Jetty 8.1.13 checks for equality of the old and the new values: >>> org.eclipse.jetty.server.session.AbstractSession#setAttribute >>> public void setAttribute(String name, Object value) >>> { >>> Object old=null; >>> synchronized (this) >>> { >>> checkValid(); >>> old=doPutOrRemove(name,value); >>> } >>> >>> if (value==null || !value.equals(old)) // <<<<< >>> { >>> if (old!=null) >>> unbindValue(name,old); >>> >>> Since SessionEntry doesn't override #equals() the check is by reference. >>> Thus no notification. >>> >>> >>> >>> On Mon, Sep 30, 2013 at 11:32 AM, Martin Grigorov >>> wrote: >>> >>>> I'll test this and let you know. >>>> >>>> >>>> On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors wrote: >>>> >>>>> Sorry for the delay, it's the weekend :) >>>>> >>>>> In our webapp we let the system administrator control the user session >>>>> timeout which we set it via the Login page as: >>>>> WebRequest webRequest = (WebRequest)RequestCycle.get().getRequest(); >>>>> HttpServletRequest httpRequest = >>>>> (HttpServletRequest)webRequest.getContainerRequest(); >>>>> httpRequest.getSession().setMaxInactiveInterval(sessionDuration); >>>>> >>>>> I set the session duration to 1 min and tried it with the new >>>>> implementation for the getSessionEntry(), waited for a good 2-3 mins and >>>>> the session is never invalidated any longer as if it's no longer touched. >>>>> My breakpoint on SessionEntry.valueUnbound() is not called either, unless >>>>> explicitly through the Logout button which calls >>>>> o.a.w.protocol.http.WebSession.get().invalidateNow(); >>>>> >>>>> This is what makes me think that going off the HttpSessionListener >>>>> might be better. >>>>> >>>>> ~ Thank you, >>>>> Paul Bors >>>>> >>>>> -Original Message- >>>>> From: Martin Grigorov [mailto:mgrigo...@apache.org] >>>>> Sent: Saturday, September 28, 2013 3:44 AM >>>>> To: users@wicket.apache.org >>>>> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 >>>>> (GlassFish v3 and v4) >>>>> >>>>> I think both suggestions should be applied. >>>>> The intentions are more clear, IMO. >>>>> >>>>> But let's wait Paul to explain what problem he faced. I don't expect >>>>> problems with session timeouts because this is managed by the web >>>>> container. If there is request then the session is touched. If the session >>>>> is not touched for some predefined time then the web container invalidates >>>>> it automatically. >>>>> >>>>> >>>>> On Sat, Sep 28, 2013 at 8:48 AM, Sven Meier wrote: >>>>> >>>>> > Martin's explanation fits the reported stacktrace nicely
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
Applying only the first change that I suggested works on all - Jetty 8, Tomcat 7 and Glassfish 4. I've used: WebRequest webRequest = (WebRequest) RequestCycle.get().getRequest(); HttpServletRequest httpRequest = (HttpServletRequest)webRequest.getContainerRequest(); httpRequest.getSession().setMaxInactiveInterval(10); and the session expires according to the web container's configurations. Jetty's Scavenger thread runs every 30 secs by default, so the session is invalidated between 1-30 secs after its expiration time. Tomcat and GF seems to do this every 60 secs by default. I'll create a ticket and commit the change. On Mon, Sep 30, 2013 at 11:55 AM, Martin Grigorov wrote: > Tomcat 7.x makes identity check: > > org.apache.catalina.session.StandardSession#setAttribute > // Call the valueUnbound() method if necessary > if (notify && (unbound != null) && (unbound != value) && > (unbound instanceof HttpSessionBindingListener)) { > > > On Mon, Sep 30, 2013 at 11:49 AM, Martin Grigorov wrote: > >> Jetty 8.1.13 checks for equality of the old and the new values: >> org.eclipse.jetty.server.session.AbstractSession#setAttribute >> public void setAttribute(String name, Object value) >> { >> Object old=null; >> synchronized (this) >> { >> checkValid(); >> old=doPutOrRemove(name,value); >> } >> >> if (value==null || !value.equals(old)) // <<<<< >> { >> if (old!=null) >> unbindValue(name,old); >> >> Since SessionEntry doesn't override #equals() the check is by reference. >> Thus no notification. >> >> >> >> On Mon, Sep 30, 2013 at 11:32 AM, Martin Grigorov >> wrote: >> >>> I'll test this and let you know. >>> >>> >>> On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors wrote: >>> >>>> Sorry for the delay, it's the weekend :) >>>> >>>> In our webapp we let the system administrator control the user session >>>> timeout which we set it via the Login page as: >>>> WebRequest webRequest = (WebRequest)RequestCycle.get().getRequest(); >>>> HttpServletRequest httpRequest = >>>> (HttpServletRequest)webRequest.getContainerRequest(); >>>> httpRequest.getSession().setMaxInactiveInterval(sessionDuration); >>>> >>>> I set the session duration to 1 min and tried it with the new >>>> implementation for the getSessionEntry(), waited for a good 2-3 mins and >>>> the session is never invalidated any longer as if it's no longer touched. >>>> My breakpoint on SessionEntry.valueUnbound() is not called either, unless >>>> explicitly through the Logout button which calls >>>> o.a.w.protocol.http.WebSession.get().invalidateNow(); >>>> >>>> This is what makes me think that going off the HttpSessionListener >>>> might be better. >>>> >>>> ~ Thank you, >>>> Paul Bors >>>> >>>> -Original Message- >>>> From: Martin Grigorov [mailto:mgrigo...@apache.org] >>>> Sent: Saturday, September 28, 2013 3:44 AM >>>> To: users@wicket.apache.org >>>> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 >>>> (GlassFish v3 and v4) >>>> >>>> I think both suggestions should be applied. >>>> The intentions are more clear, IMO. >>>> >>>> But let's wait Paul to explain what problem he faced. I don't expect >>>> problems with session timeouts because this is managed by the web >>>> container. If there is request then the session is touched. If the session >>>> is not touched for some predefined time then the web container invalidates >>>> it automatically. >>>> >>>> >>>> On Sat, Sep 28, 2013 at 8:48 AM, Sven Meier wrote: >>>> >>>> > Martin's explanation fits the reported stacktrace nicely. >>>> > >>>> > We should definitely change getSessionEntry() as proposed. I don't see >>>> > an advantage in using an HttpSessionListener though. >>>> > >>>> > @Paul: What is broken now? >>>> > >>>> > Sven >>>> > >>>> > >>>> > On 09/28/2013 12:15 AM, Paul Bors wrote: >>>> > >>>> >> I take that back, the new implementation breaks the session ti
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
Tomcat 7.x makes identity check: org.apache.catalina.session.StandardSession#setAttribute // Call the valueUnbound() method if necessary if (notify && (unbound != null) && (unbound != value) && (unbound instanceof HttpSessionBindingListener)) { On Mon, Sep 30, 2013 at 11:49 AM, Martin Grigorov wrote: > Jetty 8.1.13 checks for equality of the old and the new values: > org.eclipse.jetty.server.session.AbstractSession#setAttribute > public void setAttribute(String name, Object value) > { > Object old=null; > synchronized (this) > { > checkValid(); > old=doPutOrRemove(name,value); > } > > if (value==null || !value.equals(old)) // <<<<< > { > if (old!=null) > unbindValue(name,old); > > Since SessionEntry doesn't override #equals() the check is by reference. > Thus no notification. > > > > On Mon, Sep 30, 2013 at 11:32 AM, Martin Grigorov wrote: > >> I'll test this and let you know. >> >> >> On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors wrote: >> >>> Sorry for the delay, it's the weekend :) >>> >>> In our webapp we let the system administrator control the user session >>> timeout which we set it via the Login page as: >>> WebRequest webRequest = (WebRequest)RequestCycle.get().getRequest(); >>> HttpServletRequest httpRequest = >>> (HttpServletRequest)webRequest.getContainerRequest(); >>> httpRequest.getSession().setMaxInactiveInterval(sessionDuration); >>> >>> I set the session duration to 1 min and tried it with the new >>> implementation for the getSessionEntry(), waited for a good 2-3 mins and >>> the session is never invalidated any longer as if it's no longer touched. >>> My breakpoint on SessionEntry.valueUnbound() is not called either, unless >>> explicitly through the Logout button which calls >>> o.a.w.protocol.http.WebSession.get().invalidateNow(); >>> >>> This is what makes me think that going off the HttpSessionListener might >>> be better. >>> >>> ~ Thank you, >>> Paul Bors >>> >>> -Original Message- >>> From: Martin Grigorov [mailto:mgrigo...@apache.org] >>> Sent: Saturday, September 28, 2013 3:44 AM >>> To: users@wicket.apache.org >>> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 >>> (GlassFish v3 and v4) >>> >>> I think both suggestions should be applied. >>> The intentions are more clear, IMO. >>> >>> But let's wait Paul to explain what problem he faced. I don't expect >>> problems with session timeouts because this is managed by the web >>> container. If there is request then the session is touched. If the session >>> is not touched for some predefined time then the web container invalidates >>> it automatically. >>> >>> >>> On Sat, Sep 28, 2013 at 8:48 AM, Sven Meier wrote: >>> >>> > Martin's explanation fits the reported stacktrace nicely. >>> > >>> > We should definitely change getSessionEntry() as proposed. I don't see >>> > an advantage in using an HttpSessionListener though. >>> > >>> > @Paul: What is broken now? >>> > >>> > Sven >>> > >>> > >>> > On 09/28/2013 12:15 AM, Paul Bors wrote: >>> > >>> >> I take that back, the new implementation breaks the session timeout. >>> >> >>> >> ~ Thank you, >>> >>Paul Bors >>> >> >>> >> -Original Message- >>> >> From: Paul Bors [mailto:p...@bors.ws] >>> >> Sent: Friday, September 27, 2013 5:51 PM >>> >> To: users@wicket.apache.org >>> >> Cc: d...@wicket.apache.org >>> >> Subject: RE: Bunch of Page Expired exceptions in Wicket 6.10.0 >>> >> (GlassFish >>> >> v3 and v4) >>> >> >>> >> I tested with the proposed o.a.w.p.PageStoreManager.** >>> >> PersistentRequestAdapter#**getSessionEntry() new implementation and >>> >> it's working fine in GlassFish v3.1.2.2 >>> >> >>> >> I'll withdraw my GLASSFISH-20828 bug. >>> >> >>> >> Should I open a new Wicket ticket instead? >>> >> >>> >> I do think the second suggestion of using HttpSessionListener instead >&
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
Jetty 8.1.13 checks for equality of the old and the new values: org.eclipse.jetty.server.session.AbstractSession#setAttribute public void setAttribute(String name, Object value) { Object old=null; synchronized (this) { checkValid(); old=doPutOrRemove(name,value); } if (value==null || !value.equals(old)) // <<<<< { if (old!=null) unbindValue(name,old); Since SessionEntry doesn't override #equals() the check is by reference. Thus no notification. On Mon, Sep 30, 2013 at 11:32 AM, Martin Grigorov wrote: > I'll test this and let you know. > > > On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors wrote: > >> Sorry for the delay, it's the weekend :) >> >> In our webapp we let the system administrator control the user session >> timeout which we set it via the Login page as: >> WebRequest webRequest = (WebRequest)RequestCycle.get().getRequest(); >> HttpServletRequest httpRequest = >> (HttpServletRequest)webRequest.getContainerRequest(); >> httpRequest.getSession().setMaxInactiveInterval(sessionDuration); >> >> I set the session duration to 1 min and tried it with the new >> implementation for the getSessionEntry(), waited for a good 2-3 mins and >> the session is never invalidated any longer as if it's no longer touched. >> My breakpoint on SessionEntry.valueUnbound() is not called either, unless >> explicitly through the Logout button which calls >> o.a.w.protocol.http.WebSession.get().invalidateNow(); >> >> This is what makes me think that going off the HttpSessionListener might >> be better. >> >> ~ Thank you, >> Paul Bors >> >> -Original Message----- >> From: Martin Grigorov [mailto:mgrigo...@apache.org] >> Sent: Saturday, September 28, 2013 3:44 AM >> To: users@wicket.apache.org >> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish >> v3 and v4) >> >> I think both suggestions should be applied. >> The intentions are more clear, IMO. >> >> But let's wait Paul to explain what problem he faced. I don't expect >> problems with session timeouts because this is managed by the web >> container. If there is request then the session is touched. If the session >> is not touched for some predefined time then the web container invalidates >> it automatically. >> >> >> On Sat, Sep 28, 2013 at 8:48 AM, Sven Meier wrote: >> >> > Martin's explanation fits the reported stacktrace nicely. >> > >> > We should definitely change getSessionEntry() as proposed. I don't see >> > an advantage in using an HttpSessionListener though. >> > >> > @Paul: What is broken now? >> > >> > Sven >> > >> > >> > On 09/28/2013 12:15 AM, Paul Bors wrote: >> > >> >> I take that back, the new implementation breaks the session timeout. >> >> >> >> ~ Thank you, >> >>Paul Bors >> >> >> >> -Original Message- >> >> From: Paul Bors [mailto:p...@bors.ws] >> >> Sent: Friday, September 27, 2013 5:51 PM >> >> To: users@wicket.apache.org >> >> Cc: d...@wicket.apache.org >> >> Subject: RE: Bunch of Page Expired exceptions in Wicket 6.10.0 >> >> (GlassFish >> >> v3 and v4) >> >> >> >> I tested with the proposed o.a.w.p.PageStoreManager.** >> >> PersistentRequestAdapter#**getSessionEntry() new implementation and >> >> it's working fine in GlassFish v3.1.2.2 >> >> >> >> I'll withdraw my GLASSFISH-20828 bug. >> >> >> >> Should I open a new Wicket ticket instead? >> >> >> >> I do think the second suggestion of using HttpSessionListener instead >> >> is cleaner. >> >> >> >> ~ Thank you, >> >>Paul Bors >> >> >> >> -Original Message- >> >> From: Martin Grigorov [mailto:mgrigo...@apache.org] >> >> Sent: Friday, September 27, 2013 4:09 PM >> >> To: users@wicket.apache.org >> >> Cc: d...@wicket.apache.org >> >> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 >> >> (GlassFish >> >> v3 and v4) >> >> >> >> Reading your ticket against GF I think GF behaves correctly. But I >> >> wonder why Tomcat/Jetty don't do this. >> >> >> >> So here is what happens: >> >> >> >
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
I'll test this and let you know. On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors wrote: > Sorry for the delay, it's the weekend :) > > In our webapp we let the system administrator control the user session > timeout which we set it via the Login page as: > WebRequest webRequest = (WebRequest)RequestCycle.get().getRequest(); > HttpServletRequest httpRequest = > (HttpServletRequest)webRequest.getContainerRequest(); > httpRequest.getSession().setMaxInactiveInterval(sessionDuration); > > I set the session duration to 1 min and tried it with the new > implementation for the getSessionEntry(), waited for a good 2-3 mins and > the session is never invalidated any longer as if it's no longer touched. > My breakpoint on SessionEntry.valueUnbound() is not called either, unless > explicitly through the Logout button which calls > o.a.w.protocol.http.WebSession.get().invalidateNow(); > > This is what makes me think that going off the HttpSessionListener might > be better. > > ~ Thank you, > Paul Bors > > -Original Message- > From: Martin Grigorov [mailto:mgrigo...@apache.org] > Sent: Saturday, September 28, 2013 3:44 AM > To: users@wicket.apache.org > Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish > v3 and v4) > > I think both suggestions should be applied. > The intentions are more clear, IMO. > > But let's wait Paul to explain what problem he faced. I don't expect > problems with session timeouts because this is managed by the web > container. If there is request then the session is touched. If the session > is not touched for some predefined time then the web container invalidates > it automatically. > > > On Sat, Sep 28, 2013 at 8:48 AM, Sven Meier wrote: > > > Martin's explanation fits the reported stacktrace nicely. > > > > We should definitely change getSessionEntry() as proposed. I don't see > > an advantage in using an HttpSessionListener though. > > > > @Paul: What is broken now? > > > > Sven > > > > > > On 09/28/2013 12:15 AM, Paul Bors wrote: > > > >> I take that back, the new implementation breaks the session timeout. > >> > >> ~ Thank you, > >>Paul Bors > >> > >> -Original Message- > >> From: Paul Bors [mailto:p...@bors.ws] > >> Sent: Friday, September 27, 2013 5:51 PM > >> To: users@wicket.apache.org > >> Cc: d...@wicket.apache.org > >> Subject: RE: Bunch of Page Expired exceptions in Wicket 6.10.0 > >> (GlassFish > >> v3 and v4) > >> > >> I tested with the proposed o.a.w.p.PageStoreManager.** > >> PersistentRequestAdapter#**getSessionEntry() new implementation and > >> it's working fine in GlassFish v3.1.2.2 > >> > >> I'll withdraw my GLASSFISH-20828 bug. > >> > >> Should I open a new Wicket ticket instead? > >> > >> I do think the second suggestion of using HttpSessionListener instead > >> is cleaner. > >> > >> ~ Thank you, > >>Paul Bors > >> > >> -Original Message- > >> From: Martin Grigorov [mailto:mgrigo...@apache.org] > >> Sent: Friday, September 27, 2013 4:09 PM > >> To: users@wicket.apache.org > >> Cc: d...@wicket.apache.org > >> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 > >> (GlassFish > >> v3 and v4) > >> > >> Reading your ticket against GF I think GF behaves correctly. But I > >> wonder why Tomcat/Jetty don't do this. > >> > >> So here is what happens: > >> > >> org.apache.wicket.page.**PageStoreManager.**PersistentRequestAdapter# > >> ** > >> getSessionEntry > >> looks like : > >> private SessionEntry getSessionEntry(boolean create) { SessionEntry > >> entry = (SessionEntry)**getSessionAttribute(**getAttributeName()); > >> if (entry == null && create) > >> { > >> bind(); > >> entry = new SessionEntry(applicationName, getSessionId()); } if > >> (entry != null) { synchronized (entry) { > >> setSessionAttribute(**getAttributeName(), > >> entry); } } return entry; } > >> > >> I think the correct code should be: > >> > >> private SessionEntry getSessionEntry(boolean create) { SessionEntry > >> entry = (SessionEntry)**getSessionAttribute(**getAttributeName()); > >> if (entry == null && create) > >> { > >> bind(); > >> entry = new SessionEntry(applicationName, getSessionId()); > >
RE: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
Sorry for the delay, it's the weekend :) In our webapp we let the system administrator control the user session timeout which we set it via the Login page as: WebRequest webRequest = (WebRequest)RequestCycle.get().getRequest(); HttpServletRequest httpRequest = (HttpServletRequest)webRequest.getContainerRequest(); httpRequest.getSession().setMaxInactiveInterval(sessionDuration); I set the session duration to 1 min and tried it with the new implementation for the getSessionEntry(), waited for a good 2-3 mins and the session is never invalidated any longer as if it's no longer touched. My breakpoint on SessionEntry.valueUnbound() is not called either, unless explicitly through the Logout button which calls o.a.w.protocol.http.WebSession.get().invalidateNow(); This is what makes me think that going off the HttpSessionListener might be better. ~ Thank you, Paul Bors -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Saturday, September 28, 2013 3:44 AM To: users@wicket.apache.org Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4) I think both suggestions should be applied. The intentions are more clear, IMO. But let's wait Paul to explain what problem he faced. I don't expect problems with session timeouts because this is managed by the web container. If there is request then the session is touched. If the session is not touched for some predefined time then the web container invalidates it automatically. On Sat, Sep 28, 2013 at 8:48 AM, Sven Meier wrote: > Martin's explanation fits the reported stacktrace nicely. > > We should definitely change getSessionEntry() as proposed. I don't see > an advantage in using an HttpSessionListener though. > > @Paul: What is broken now? > > Sven > > > On 09/28/2013 12:15 AM, Paul Bors wrote: > >> I take that back, the new implementation breaks the session timeout. >> >> ~ Thank you, >>Paul Bors >> >> -Original Message- >> From: Paul Bors [mailto:p...@bors.ws] >> Sent: Friday, September 27, 2013 5:51 PM >> To: users@wicket.apache.org >> Cc: d...@wicket.apache.org >> Subject: RE: Bunch of Page Expired exceptions in Wicket 6.10.0 >> (GlassFish >> v3 and v4) >> >> I tested with the proposed o.a.w.p.PageStoreManager.** >> PersistentRequestAdapter#**getSessionEntry() new implementation and >> it's working fine in GlassFish v3.1.2.2 >> >> I'll withdraw my GLASSFISH-20828 bug. >> >> Should I open a new Wicket ticket instead? >> >> I do think the second suggestion of using HttpSessionListener instead >> is cleaner. >> >> ~ Thank you, >>Paul Bors >> >> -----Original Message- >> From: Martin Grigorov [mailto:mgrigo...@apache.org] >> Sent: Friday, September 27, 2013 4:09 PM >> To: users@wicket.apache.org >> Cc: d...@wicket.apache.org >> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 >> (GlassFish >> v3 and v4) >> >> Reading your ticket against GF I think GF behaves correctly. But I >> wonder why Tomcat/Jetty don't do this. >> >> So here is what happens: >> >> org.apache.wicket.page.**PageStoreManager.**PersistentRequestAdapter# >> ** >> getSessionEntry >> looks like : >> private SessionEntry getSessionEntry(boolean create) { SessionEntry >> entry = (SessionEntry)**getSessionAttribute(**getAttributeName()); >> if (entry == null && create) >> { >> bind(); >> entry = new SessionEntry(applicationName, getSessionId()); } if >> (entry != null) { synchronized (entry) { >> setSessionAttribute(**getAttributeName(), >> entry); } } return entry; } >> >> I think the correct code should be: >> >> private SessionEntry getSessionEntry(boolean create) { SessionEntry >> entry = (SessionEntry)**getSessionAttribute(**getAttributeName()); >> if (entry == null && create) >> { >> bind(); >> entry = new SessionEntry(applicationName, getSessionId()); >> setSessionAttribute(**getAttributeName(), entry); } return entry; } >> I.e. set the SessionEntry as an attribute in the http session only >> when it is created. >> >> Because with the current code we call >> "setSessionAttribute(**getAttributeName(), entry);" even with already >> existing entries and this leads to notifications to >> HttpSessionBindingListener - new value is bound, old value is removed. >> >> I guess Tomcat and Jetty optimize this by doing identity check. >> >> Another solution would be SessionEntry to implement >> HttpSession
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
I think both suggestions should be applied. The intentions are more clear, IMO. But let's wait Paul to explain what problem he faced. I don't expect problems with session timeouts because this is managed by the web container. If there is request then the session is touched. If the session is not touched for some predefined time then the web container invalidates it automatically. On Sat, Sep 28, 2013 at 8:48 AM, Sven Meier wrote: > Martin's explanation fits the reported stacktrace nicely. > > We should definitely change getSessionEntry() as proposed. I don't see an > advantage in using an HttpSessionListener though. > > @Paul: What is broken now? > > Sven > > > On 09/28/2013 12:15 AM, Paul Bors wrote: > >> I take that back, the new implementation breaks the session timeout. >> >> ~ Thank you, >>Paul Bors >> >> -Original Message- >> From: Paul Bors [mailto:p...@bors.ws] >> Sent: Friday, September 27, 2013 5:51 PM >> To: users@wicket.apache.org >> Cc: d...@wicket.apache.org >> Subject: RE: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish >> v3 and v4) >> >> I tested with the proposed o.a.w.p.PageStoreManager.** >> PersistentRequestAdapter#**getSessionEntry() new implementation and it's >> working fine in GlassFish v3.1.2.2 >> >> I'll withdraw my GLASSFISH-20828 bug. >> >> Should I open a new Wicket ticket instead? >> >> I do think the second suggestion of using HttpSessionListener instead is >> cleaner. >> >> ~ Thank you, >> Paul Bors >> >> -----Original Message- >> From: Martin Grigorov [mailto:mgrigo...@apache.org] >> Sent: Friday, September 27, 2013 4:09 PM >> To: users@wicket.apache.org >> Cc: d...@wicket.apache.org >> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish >> v3 and v4) >> >> Reading your ticket against GF I think GF behaves correctly. But I wonder >> why Tomcat/Jetty don't do this. >> >> So here is what happens: >> >> org.apache.wicket.page.**PageStoreManager.**PersistentRequestAdapter#** >> getSessionEntry >> looks like : >> private SessionEntry getSessionEntry(boolean create) { SessionEntry entry >> = (SessionEntry)**getSessionAttribute(**getAttributeName()); >> if (entry == null && create) >> { >> bind(); >> entry = new SessionEntry(applicationName, getSessionId()); } if (entry >> != null) { synchronized (entry) { setSessionAttribute(**getAttributeName(), >> entry); } } return entry; } >> >> I think the correct code should be: >> >> private SessionEntry getSessionEntry(boolean create) { SessionEntry entry >> = (SessionEntry)**getSessionAttribute(**getAttributeName()); >> if (entry == null && create) >> { >> bind(); >> entry = new SessionEntry(applicationName, getSessionId()); >> setSessionAttribute(**getAttributeName(), entry); } return entry; } >> I.e. set the SessionEntry as an attribute in the http session only when it >> is created. >> >> Because with the current code we call >> "setSessionAttribute(**getAttributeName(), entry);" even with already >> existing entries and this leads to notifications to >> HttpSessionBindingListener - new value is bound, old value is removed. >> >> I guess Tomcat and Jetty optimize this by doing identity check. >> >> Another solution would be SessionEntry to implement HttpSessionListener >> instead and check the sessionId of the unbound session against its own one >> and clean the data store if they are equal. >> >> >> >> >> >> On Fri, Sep 27, 2013 at 9:20 PM, Paul Bors wrote: >> >> Created >> https://java.net/jira/browse/**GLASSFISH-20828<https://java.net/jira/browse/GLASSFISH-20828> >>> "HttpSessionBindingListener.**valueUnbound() is always called right >>> after >>> valueBound() with a null HttpSessionBindingEvent.**getValue()" >>> >>> Let's see what becomes of this... >>> >>> >>> >>> - >>> ~ Thank you, >>> p...@bors.ws >>> -- >>> View this message in context: >>> http://apache-wicket.1842946.**n4.nabble.com/Bunch-of-Page-** >>> Expired-excep<http://apache-wicket.1842946.n4.nabble.com/Bunch-of-Page-Expired-excep> >>> tions-in-Wicket-6-10-0-**tp4661502p4661582.html >>> Sent from the Users forum mailing list archive at Nabble.com. >>> >>> --**--** >>> - >>> To unsubscribe, e-mail: >>> users-unsubscribe@wicket.**apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >>> >> >> --**--**- >> To unsubscribe, e-mail: >> users-unsubscribe@wicket.**apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@wicket.**apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
Martin's explanation fits the reported stacktrace nicely. We should definitely change getSessionEntry() as proposed. I don't see an advantage in using an HttpSessionListener though. @Paul: What is broken now? Sven On 09/28/2013 12:15 AM, Paul Bors wrote: I take that back, the new implementation breaks the session timeout. ~ Thank you, Paul Bors -Original Message- From: Paul Bors [mailto:p...@bors.ws] Sent: Friday, September 27, 2013 5:51 PM To: users@wicket.apache.org Cc: d...@wicket.apache.org Subject: RE: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4) I tested with the proposed o.a.w.p.PageStoreManager.PersistentRequestAdapter#getSessionEntry() new implementation and it's working fine in GlassFish v3.1.2.2 I'll withdraw my GLASSFISH-20828 bug. Should I open a new Wicket ticket instead? I do think the second suggestion of using HttpSessionListener instead is cleaner. ~ Thank you, Paul Bors -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Friday, September 27, 2013 4:09 PM To: users@wicket.apache.org Cc: d...@wicket.apache.org Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4) Reading your ticket against GF I think GF behaves correctly. But I wonder why Tomcat/Jetty don't do this. So here is what happens: org.apache.wicket.page.PageStoreManager.PersistentRequestAdapter#getSessionEntry looks like : private SessionEntry getSessionEntry(boolean create) { SessionEntry entry = (SessionEntry)getSessionAttribute(getAttributeName()); if (entry == null && create) { bind(); entry = new SessionEntry(applicationName, getSessionId()); } if (entry != null) { synchronized (entry) { setSessionAttribute(getAttributeName(), entry); } } return entry; } I think the correct code should be: private SessionEntry getSessionEntry(boolean create) { SessionEntry entry = (SessionEntry)getSessionAttribute(getAttributeName()); if (entry == null && create) { bind(); entry = new SessionEntry(applicationName, getSessionId()); setSessionAttribute(getAttributeName(), entry); } return entry; } I.e. set the SessionEntry as an attribute in the http session only when it is created. Because with the current code we call "setSessionAttribute(getAttributeName(), entry);" even with already existing entries and this leads to notifications to HttpSessionBindingListener - new value is bound, old value is removed. I guess Tomcat and Jetty optimize this by doing identity check. Another solution would be SessionEntry to implement HttpSessionListener instead and check the sessionId of the unbound session against its own one and clean the data store if they are equal. On Fri, Sep 27, 2013 at 9:20 PM, Paul Bors wrote: Created https://java.net/jira/browse/GLASSFISH-20828 "HttpSessionBindingListener.valueUnbound() is always called right after valueBound() with a null HttpSessionBindingEvent.getValue()" Let's see what becomes of this... - ~ Thank you, p...@bors.ws -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Bunch-of-Page-Expired-excep tions-in-Wicket-6-10-0-tp4661502p4661582.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
I take that back, the new implementation breaks the session timeout. ~ Thank you, Paul Bors -Original Message- From: Paul Bors [mailto:p...@bors.ws] Sent: Friday, September 27, 2013 5:51 PM To: users@wicket.apache.org Cc: d...@wicket.apache.org Subject: RE: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4) I tested with the proposed o.a.w.p.PageStoreManager.PersistentRequestAdapter#getSessionEntry() new implementation and it's working fine in GlassFish v3.1.2.2 I'll withdraw my GLASSFISH-20828 bug. Should I open a new Wicket ticket instead? I do think the second suggestion of using HttpSessionListener instead is cleaner. ~ Thank you, Paul Bors -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Friday, September 27, 2013 4:09 PM To: users@wicket.apache.org Cc: d...@wicket.apache.org Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4) Reading your ticket against GF I think GF behaves correctly. But I wonder why Tomcat/Jetty don't do this. So here is what happens: org.apache.wicket.page.PageStoreManager.PersistentRequestAdapter#getSessionEntry looks like : private SessionEntry getSessionEntry(boolean create) { SessionEntry entry = (SessionEntry)getSessionAttribute(getAttributeName()); if (entry == null && create) { bind(); entry = new SessionEntry(applicationName, getSessionId()); } if (entry != null) { synchronized (entry) { setSessionAttribute(getAttributeName(), entry); } } return entry; } I think the correct code should be: private SessionEntry getSessionEntry(boolean create) { SessionEntry entry = (SessionEntry)getSessionAttribute(getAttributeName()); if (entry == null && create) { bind(); entry = new SessionEntry(applicationName, getSessionId()); setSessionAttribute(getAttributeName(), entry); } return entry; } I.e. set the SessionEntry as an attribute in the http session only when it is created. Because with the current code we call "setSessionAttribute(getAttributeName(), entry);" even with already existing entries and this leads to notifications to HttpSessionBindingListener - new value is bound, old value is removed. I guess Tomcat and Jetty optimize this by doing identity check. Another solution would be SessionEntry to implement HttpSessionListener instead and check the sessionId of the unbound session against its own one and clean the data store if they are equal. On Fri, Sep 27, 2013 at 9:20 PM, Paul Bors wrote: > Created https://java.net/jira/browse/GLASSFISH-20828 > "HttpSessionBindingListener.valueUnbound() is always called right > after > valueBound() with a null HttpSessionBindingEvent.getValue()" > > Let's see what becomes of this... > > > > - > ~ Thank you, > p...@bors.ws > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Bunch-of-Page-Expired-excep > tions-in-Wicket-6-10-0-tp4661502p4661582.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
I tested with the proposed o.a.w.p.PageStoreManager.PersistentRequestAdapter#getSessionEntry() new implementation and it's working fine in GlassFish v3.1.2.2 I'll withdraw my GLASSFISH-20828 bug. Should I open a new Wicket ticket instead? I do think the second suggestion of using HttpSessionListener instead is cleaner. ~ Thank you, Paul Bors -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Friday, September 27, 2013 4:09 PM To: users@wicket.apache.org Cc: d...@wicket.apache.org Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4) Reading your ticket against GF I think GF behaves correctly. But I wonder why Tomcat/Jetty don't do this. So here is what happens: org.apache.wicket.page.PageStoreManager.PersistentRequestAdapter#getSessionEntry looks like : private SessionEntry getSessionEntry(boolean create) { SessionEntry entry = (SessionEntry)getSessionAttribute(getAttributeName()); if (entry == null && create) { bind(); entry = new SessionEntry(applicationName, getSessionId()); } if (entry != null) { synchronized (entry) { setSessionAttribute(getAttributeName(), entry); } } return entry; } I think the correct code should be: private SessionEntry getSessionEntry(boolean create) { SessionEntry entry = (SessionEntry)getSessionAttribute(getAttributeName()); if (entry == null && create) { bind(); entry = new SessionEntry(applicationName, getSessionId()); setSessionAttribute(getAttributeName(), entry); } return entry; } I.e. set the SessionEntry as an attribute in the http session only when it is created. Because with the current code we call "setSessionAttribute(getAttributeName(), entry);" even with already existing entries and this leads to notifications to HttpSessionBindingListener - new value is bound, old value is removed. I guess Tomcat and Jetty optimize this by doing identity check. Another solution would be SessionEntry to implement HttpSessionListener instead and check the sessionId of the unbound session against its own one and clean the data store if they are equal. On Fri, Sep 27, 2013 at 9:20 PM, Paul Bors wrote: > Created https://java.net/jira/browse/GLASSFISH-20828 > "HttpSessionBindingListener.valueUnbound() is always called right > after > valueBound() with a null HttpSessionBindingEvent.getValue()" > > Let's see what becomes of this... > > > > - > ~ Thank you, > p...@bors.ws > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Bunch-of-Page-Expired-excep > tions-in-Wicket-6-10-0-tp4661502p4661582.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
Reading your ticket against GF I think GF behaves correctly. But I wonder why Tomcat/Jetty don't do this. So here is what happens: org.apache.wicket.page.PageStoreManager.PersistentRequestAdapter#getSessionEntry looks like : private SessionEntry getSessionEntry(boolean create) { SessionEntry entry = (SessionEntry)getSessionAttribute(getAttributeName()); if (entry == null && create) { bind(); entry = new SessionEntry(applicationName, getSessionId()); } if (entry != null) { synchronized (entry) { setSessionAttribute(getAttributeName(), entry); } } return entry; } I think the correct code should be: private SessionEntry getSessionEntry(boolean create) { SessionEntry entry = (SessionEntry)getSessionAttribute(getAttributeName()); if (entry == null && create) { bind(); entry = new SessionEntry(applicationName, getSessionId()); setSessionAttribute(getAttributeName(), entry); } return entry; } I.e. set the SessionEntry as an attribute in the http session only when it is created. Because with the current code we call "setSessionAttribute(getAttributeName(), entry);" even with already existing entries and this leads to notifications to HttpSessionBindingListener - new value is bound, old value is removed. I guess Tomcat and Jetty optimize this by doing identity check. Another solution would be SessionEntry to implement HttpSessionListener instead and check the sessionId of the unbound session against its own one and clean the data store if they are equal. On Fri, Sep 27, 2013 at 9:20 PM, Paul Bors wrote: > Created https://java.net/jira/browse/GLASSFISH-20828 > "HttpSessionBindingListener.valueUnbound() is always called right after > valueBound() with a null HttpSessionBindingEvent.getValue()" > > Let's see what becomes of this... > > > > - > ~ Thank you, > p...@bors.ws > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Bunch-of-Page-Expired-exceptions-in-Wicket-6-10-0-tp4661502p4661582.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
RE: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
Created https://java.net/jira/browse/GLASSFISH-20828 "HttpSessionBindingListener.valueUnbound() is always called right after valueBound() with a null HttpSessionBindingEvent.getValue()" Let's see what becomes of this... - ~ Thank you, p...@bors.ws -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Bunch-of-Page-Expired-exceptions-in-Wicket-6-10-0-tp4661502p4661582.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
The closest I came to finding any ticket in GF's queue was: https://java.net/jira/browse/GLASSFISH-4373 "Remove http session attributes only after invoking HttpSessionListener.sessionDestroyed()" Which was closed with some defensive comment about how GF does obey the servlet specs and ... Now that I knew what to look for I observed the following strange behavior in GlassFish v3. Each time GF is calling o.a.w.p.PageStoreManager.SessionEntry#valueUnbound it's calling it in pairs of valueBound() immediate fallowed by valueUnbound() with one exception, the HttpSessionBindingEvent#getName() is null for the call to valueUnbound(). It's actually always null until the Object is really unbound from the session which I tested on Session#invalidateNow() and session timeout. This is definitely a GF bug, but I am wondering if it's worth the effort to put in a condition for the null check on the HttpSessionBindingEvent#getName() whenever the valueUnbound() is called inside the default PageStoreManager.SessionEntry? Otherwise I'll just register my own PageStoreManager to go with this fix. It might make it easier for me if I could extend just the private SessionEntry, but that'll really be a nice to have at this point. ~ Thank you, Paul Bors -Original Message- From: Paul Bors [mailto:p...@bors.ws] Sent: Friday, September 27, 2013 11:04 AM To: users@wicket.apache.org Subject: RE: Bunch of Page Expired exceptions in Wicket 6.10.0 I so knew it! It also affects GlassFish v3.1.2.2 which I am using. Thanks again guys, I'll look into it from my end and see what GF team has to say about it. In the mid time, I'll go back to Wicket 6.10.0 and just register my own PageStoreManager. ~ Thank you, Paul Bors -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Friday, September 27, 2013 10:09 AM To: users@wicket.apache.org Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 I created a simple app and tested it on these 3 servers + Jetty 8.1.13. The app shows that SessionEntry#valueUnbound is called only for Glassfish 4.0. Reading HttpSessionBindingListener's javadoc: * Causes an object to be notified when it is bound to * or unbound from a session. The object is notified * by an {@link HttpSessionBindingEvent} object. This may be as a result * of a servlet programmer explicitly unbinding an attribute from a session, * due to a session being invalidated, or due to a session timing out. for me this is a bug in GF. I didn't bother to search in their issue trackers. Usually their servers are very slow. Additionally they do not bother to respond/comment. They just close the ticket at some point... I don't like GF and I will not try to help them. On Fri, Sep 27, 2013 at 3:43 PM, Sven Meier wrote: > Do you have a reference? Do we have to do something about it? > > Regards > Sven > > > On 09/27/2013 10:24 AM, Martin Grigorov wrote: > >> It is the buggy Glassfish. >> Jetty 7.6.13 and Tomcat 7.0.45 (being voted atm) work fine. >> But Glassfish 4.0 (build 89) >> calls >> org.apache.wicket.page.**PageStoreManager.SessionEntry#**valueUnbound >> for >> any attribute added to the session. >> >> >> On Fri, Sep 27, 2013 at 9:41 AM, Sven Meier wrote: >> >> Hi, >>> >>> >>> With this change any kind of attribute added to the http session >>> causes >>>> >>> total removal >>> >>> a HttpSessionBindingListener listens to removal of itself only. Any >>> other session attribute is irrelevant. >>> >>> It seems an existing sessionEntry is replaced with a new one: >>> >>> org.apache.wicket.page.PageStoreManager$SessionEntry. >>> valueUnbound(PageStoreManager.java:307) >>>at >>> ... >>> >>> org.apache.wicket.page.RequestAdapter.setSessionAttribute(** >>> RequestAdapter.java:89) >>>at >>> org.apache.wicket.page.PageStoreManager$ >>> PersistentRequestAdapter.** >>> getSessionEntry(PageStoreManager.java:378) >>> >>> >>> >>> The question is why the request adapter does not find the existing >>> sessionEntry although it is already there (and then replaced afterwards). >>> >>> A quickstart would help to narrow down the problem. >>> >>> Sven >>> >>> >>> >>> On 09/26/2013 11:46 PM, Paul Bors wrote: >>> >>> By rolling back to Wicket 6.9.0 I can confirm that the >>> PageStoreManager >>>> works and I do see my page store content via DiskStoreBrowserPage. >>>&g
RE: Bunch of Page Expired exceptions in Wicket 6.10.0
I so knew it! It also affects GlassFish v3.1.2.2 which I am using. Thanks again guys, I'll look into it from my end and see what GF team has to say about it. In the mid time, I'll go back to Wicket 6.10.0 and just register my own PageStoreManager. ~ Thank you, Paul Bors -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Friday, September 27, 2013 10:09 AM To: users@wicket.apache.org Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 I created a simple app and tested it on these 3 servers + Jetty 8.1.13. The app shows that SessionEntry#valueUnbound is called only for Glassfish 4.0. Reading HttpSessionBindingListener's javadoc: * Causes an object to be notified when it is bound to * or unbound from a session. The object is notified * by an {@link HttpSessionBindingEvent} object. This may be as a result * of a servlet programmer explicitly unbinding an attribute from a session, * due to a session being invalidated, or due to a session timing out. for me this is a bug in GF. I didn't bother to search in their issue trackers. Usually their servers are very slow. Additionally they do not bother to respond/comment. They just close the ticket at some point... I don't like GF and I will not try to help them. On Fri, Sep 27, 2013 at 3:43 PM, Sven Meier wrote: > Do you have a reference? Do we have to do something about it? > > Regards > Sven > > > On 09/27/2013 10:24 AM, Martin Grigorov wrote: > >> It is the buggy Glassfish. >> Jetty 7.6.13 and Tomcat 7.0.45 (being voted atm) work fine. >> But Glassfish 4.0 (build 89) >> calls >> org.apache.wicket.page.**PageStoreManager.SessionEntry#**valueUnbound >> for >> any attribute added to the session. >> >> >> On Fri, Sep 27, 2013 at 9:41 AM, Sven Meier wrote: >> >> Hi, >>> >>> >>> With this change any kind of attribute added to the http session >>> causes >>>> >>> total removal >>> >>> a HttpSessionBindingListener listens to removal of itself only. Any >>> other session attribute is irrelevant. >>> >>> It seems an existing sessionEntry is replaced with a new one: >>> >>> org.apache.wicket.page.PageStoreManager$SessionEntry. >>> valueUnbound(PageStoreManager.java:307) >>>at >>> ... >>> >>> org.apache.wicket.page.RequestAdapter.setSessionAttribute(** >>> RequestAdapter.java:89) >>>at >>> org.apache.wicket.page.PageStoreManager$ >>> PersistentRequestAdapter.** >>> getSessionEntry(PageStoreManager.java:378) >>> >>> >>> >>> The question is why the request adapter does not find the existing >>> sessionEntry although it is already there (and then replaced afterwards). >>> >>> A quickstart would help to narrow down the problem. >>> >>> Sven >>> >>> >>> >>> On 09/26/2013 11:46 PM, Paul Bors wrote: >>> >>> By rolling back to Wicket 6.9.0 I can confirm that the >>> PageStoreManager >>>> works and I do see my page store content via DiskStoreBrowserPage. >>>> >>>> For a bit more environmental details, I was running my tests on top >>>> of GlassFish 3.1.2.2 >>>> >>>> Thanks for the heads up Martin! >>>> For now I'll stick to 6.9.x :) >>>> >>>> ~ Thank you, >>>> Paul Bors >>>> >>>> -Original Message- >>>> From: Martin Grigorov [mailto:mgrigo...@apache.org] >>>> Sent: Thursday, September 26, 2013 5:01 PM >>>> To: users@wicket.apache.org >>>> Cc: Sven Meier >>>> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 >>>> >>>> The problem seems to be caused by >>>> http://issues.apache.org/jira/browse/WICKET-5164<http://issues. >>>> apache.org/jira/**browse/WICKET-5164> >>>> <http://**issues.apache.org/jira/browse/**WICKET-5164<http://issues >>>> .apache.org/jira/browse/WICKET-5164> >>>> > >>>> >>>> With this change any kind of attribute added to the http session >>>> causes total removal of all data from the disk store. >>>> This looks quite serious. >>>> >>>> @Sven: can you take a look. >>>> >>>> >>>> On Thu, Sep 26, 2013 at 10:30 PM, Paul Bors wrote: >>>> >>>> Hey Martin, >>
RE: Bunch of Page Expired exceptions in Wicket 6.10.0
No, I mean TabbedPanel or the Ajax equivalent. http://www.wicket-library.com/wicket-examples/compref/wicket/bookmarkable/or g.apache.wicket.examples.compref.TabbedPanelPage;jsessionid=1D5D59D85C73C7FA E205D7C7C0154C5A?0 However, this is simply reproducible via any access to a page from the disk store since it's always empty such as submitting a form twice in a row or using the back button in the browser. ~ Thank you, Paul Bors -Original Message- From: miguel [mailto:mig...@thedeanda.com] Sent: Friday, September 27, 2013 2:20 AM To: users@wicket.apache.org Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 by tabs do you mean browser tabs? if you have 2 tabs: http://localhost:8080/Foo and http://localhost:8081/Bar then reloading each tab will often invalidate the previous tab. the session cookie is overwritten. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Bunch-of-Page-Expired-exceptions- in-Wicket-6-10-0-tp4661502p4661540.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Bunch of Page Expired exceptions in Wicket 6.10.0
I created a simple app and tested it on these 3 servers + Jetty 8.1.13. The app shows that SessionEntry#valueUnbound is called only for Glassfish 4.0. Reading HttpSessionBindingListener's javadoc: * Causes an object to be notified when it is bound to * or unbound from a session. The object is notified * by an {@link HttpSessionBindingEvent} object. This may be as a result * of a servlet programmer explicitly unbinding an attribute from a session, * due to a session being invalidated, or due to a session timing out. for me this is a bug in GF. I didn't bother to search in their issue trackers. Usually their servers are very slow. Additionally they do not bother to respond/comment. They just close the ticket at some point... I don't like GF and I will not try to help them. On Fri, Sep 27, 2013 at 3:43 PM, Sven Meier wrote: > Do you have a reference? Do we have to do something about it? > > Regards > Sven > > > On 09/27/2013 10:24 AM, Martin Grigorov wrote: > >> It is the buggy Glassfish. >> Jetty 7.6.13 and Tomcat 7.0.45 (being voted atm) work fine. >> But Glassfish 4.0 (build 89) >> calls org.apache.wicket.page.**PageStoreManager.SessionEntry#**valueUnbound >> for >> any attribute added to the session. >> >> >> On Fri, Sep 27, 2013 at 9:41 AM, Sven Meier wrote: >> >> Hi, >>> >>> >>> With this change any kind of attribute added to the http session causes >>>> >>> total removal >>> >>> a HttpSessionBindingListener listens to removal of itself only. Any other >>> session attribute is irrelevant. >>> >>> It seems an existing sessionEntry is replaced with a new one: >>> >>> org.apache.wicket.page.PageStoreManager$SessionEntry. >>> valueUnbound(PageStoreManager.java:307) >>>at >>> ... >>> >>> org.apache.wicket.page.RequestAdapter.setSessionAttribute(** >>> RequestAdapter.java:89) >>>at >>> org.apache.wicket.page.PageStoreManager$ >>> PersistentRequestAdapter.** >>> getSessionEntry(PageStoreManager.java:378) >>> >>> >>> >>> The question is why the request adapter does not find the existing >>> sessionEntry although it is already there (and then replaced afterwards). >>> >>> A quickstart would help to narrow down the problem. >>> >>> Sven >>> >>> >>> >>> On 09/26/2013 11:46 PM, Paul Bors wrote: >>> >>> By rolling back to Wicket 6.9.0 I can confirm that the PageStoreManager >>>> works and I do see my page store content via DiskStoreBrowserPage. >>>> >>>> For a bit more environmental details, I was running my tests on top of >>>> GlassFish 3.1.2.2 >>>> >>>> Thanks for the heads up Martin! >>>> For now I'll stick to 6.9.x :) >>>> >>>> ~ Thank you, >>>> Paul Bors >>>> >>>> -Original Message- >>>> From: Martin Grigorov [mailto:mgrigo...@apache.org] >>>> Sent: Thursday, September 26, 2013 5:01 PM >>>> To: users@wicket.apache.org >>>> Cc: Sven Meier >>>> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 >>>> >>>> The problem seems to be caused by >>>> http://issues.apache.org/jira/browse/WICKET-5164<http://issues.apache.org/jira/**browse/WICKET-5164> >>>> <http://**issues.apache.org/jira/browse/**WICKET-5164<http://issues.apache.org/jira/browse/WICKET-5164> >>>> > >>>> >>>> With this change any kind of attribute added to the http session causes >>>> total removal of all data from the disk store. >>>> This looks quite serious. >>>> >>>> @Sven: can you take a look. >>>> >>>> >>>> On Thu, Sep 26, 2013 at 10:30 PM, Paul Bors wrote: >>>> >>>> Hey Martin, >>>> >>>>> >>>>> >>>>> So I put in my breakpoint and it looks like that my page store is >>>>> always empty, is always being invalidated by two repeated stack traces >>>>> that come in the following order: >>>>> >>>>> >>>>> >>>>> http-thread-pool-5311(1)@8339 daemon, prio=5, in group >>>>> 'grizzly-kernel', >>>>> status: 'RUNNING' >>>>> >>>>>
Re: Bunch of Page Expired exceptions in Wicket 6.10.0
Do you have a reference? Do we have to do something about it? Regards Sven On 09/27/2013 10:24 AM, Martin Grigorov wrote: It is the buggy Glassfish. Jetty 7.6.13 and Tomcat 7.0.45 (being voted atm) work fine. But Glassfish 4.0 (build 89) calls org.apache.wicket.page.PageStoreManager.SessionEntry#valueUnbound for any attribute added to the session. On Fri, Sep 27, 2013 at 9:41 AM, Sven Meier wrote: Hi, With this change any kind of attribute added to the http session causes total removal a HttpSessionBindingListener listens to removal of itself only. Any other session attribute is irrelevant. It seems an existing sessionEntry is replaced with a new one: org.apache.wicket.page.**PageStoreManager$SessionEntry.** valueUnbound(PageStoreManager.**java:307) at ... org.apache.wicket.page.**RequestAdapter.**setSessionAttribute(** RequestAdapter.java:89) at org.apache.wicket.page.**PageStoreManager$**PersistentRequestAdapter.** getSessionEntry(**PageStoreManager.java:378) The question is why the request adapter does not find the existing sessionEntry although it is already there (and then replaced afterwards). A quickstart would help to narrow down the problem. Sven On 09/26/2013 11:46 PM, Paul Bors wrote: By rolling back to Wicket 6.9.0 I can confirm that the PageStoreManager works and I do see my page store content via DiskStoreBrowserPage. For a bit more environmental details, I was running my tests on top of GlassFish 3.1.2.2 Thanks for the heads up Martin! For now I'll stick to 6.9.x :) ~ Thank you, Paul Bors -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Thursday, September 26, 2013 5:01 PM To: users@wicket.apache.org Cc: Sven Meier Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 The problem seems to be caused by http://issues.apache.org/jira/**browse/WICKET-5164<http://issues.apache.org/jira/browse/WICKET-5164> With this change any kind of attribute added to the http session causes total removal of all data from the disk store. This looks quite serious. @Sven: can you take a look. On Thu, Sep 26, 2013 at 10:30 PM, Paul Bors wrote: Hey Martin, So I put in my breakpoint and it looks like that my page store is always empty, is always being invalidated by two repeated stack traces that come in the following order: http-thread-pool-5311(1)@8339 daemon, prio=5, in group 'grizzly-kernel', status: 'RUNNING' at org.apache.wicket.pageStore.**DefaultPageStore.** removePageData(DefaultPag eStore.java:109) at org.apache.wicket.pageStore.**DefaultPageStore.unbind(** DefaultPageStore.j ava:161) at org.apache.wicket.page.**PageStoreManager$SessionEntry.** valueUnbound(Page StoreManager.java:307) at org.apache.catalina.session.**StandardSession.setAttribute(** StandardSessi on.java:1738) at org.apache.catalina.session.**StandardSessionFacade.** setAttribute(Standar dSessionFacade.java:178) at org.apache.wicket.session.**HttpSessionStore.setAttribute(** HttpSessionSto re.java:344) at org.apache.wicket.Session.**setAttribute(Session.java:848) at org.apache.wicket.page.**DefaultPageManagerContext.** setSessionAttribute(D efaultPageManagerContext.java:**99) at org.apache.wicket.page.**RequestAdapter.**setSessionAttribute(** RequestAdapt er.java:89) at org.apache.wicket.page.**PageStoreManager$** PersistentRequestAdapter.getSe ssionEntry(PageStoreManager.**java:378) at org.apache.wicket.page.**PageStoreManager$** PersistentRequestAdapter.getPa ge(PageStoreManager.java:349) at org.apache.wicket.page.**AbstractPageManager.getPage(** AbstractPageManager .java:107) at org.apache.wicket.page.**PageManagerDecorator.getPage(** PageManagerDecorat or.java:52) at org.apache.wicket.page.**PageAccessSynchronizer$2.** getPage(PageAccessSync hronizer.java:257) at org.apache.wicket.**DefaultMapperContext.**getPageInstance(** DefaultMapperCo ntext.java:148) at org.apache.wicket.core.**request.handler.PageProvider.** getStoredPage(Page Provider.java:296) at org.apache.wicket.core.**request.handler.PageProvider.** resolvePageInstanc e(PageProvider.java:261) at org.apache.wicket.core.**request.handler.PageProvider.** getPageInstance(Pa geProvider.java:166) at org.apache.wicket.core.**request.handler.** ListenerInterfaceRequestHandle**r .getPage(**ListenerInterfaceRequestHandle**r.java:96) at org.apache.wicket.core.**request.handler.** ListenerInterfaceRequestHandle**r .respond(**ListenerInterfaceRequestHandle**r.java:157) at org.apache.wick
Re: Bunch of Page Expired exceptions in Wicket 6.10.0
It is the buggy Glassfish. Jetty 7.6.13 and Tomcat 7.0.45 (being voted atm) work fine. But Glassfish 4.0 (build 89) calls org.apache.wicket.page.PageStoreManager.SessionEntry#valueUnbound for any attribute added to the session. On Fri, Sep 27, 2013 at 9:41 AM, Sven Meier wrote: > Hi, > > > >With this change any kind of attribute added to the http session causes > total removal > > a HttpSessionBindingListener listens to removal of itself only. Any other > session attribute is irrelevant. > > It seems an existing sessionEntry is replaced with a new one: > > org.apache.wicket.page.**PageStoreManager$SessionEntry.** > valueUnbound(PageStoreManager.**java:307) > at > ... > > org.apache.wicket.page.**RequestAdapter.**setSessionAttribute(** > RequestAdapter.java:89) > at > org.apache.wicket.page.**PageStoreManager$**PersistentRequestAdapter.** > getSessionEntry(**PageStoreManager.java:378) > > > The question is why the request adapter does not find the existing > sessionEntry although it is already there (and then replaced afterwards). > > A quickstart would help to narrow down the problem. > > Sven > > > > On 09/26/2013 11:46 PM, Paul Bors wrote: > >> By rolling back to Wicket 6.9.0 I can confirm that the PageStoreManager >> works and I do see my page store content via DiskStoreBrowserPage. >> >> For a bit more environmental details, I was running my tests on top of >> GlassFish 3.1.2.2 >> >> Thanks for the heads up Martin! >> For now I'll stick to 6.9.x :) >> >> ~ Thank you, >>Paul Bors >> >> -Original Message- >> From: Martin Grigorov [mailto:mgrigo...@apache.org] >> Sent: Thursday, September 26, 2013 5:01 PM >> To: users@wicket.apache.org >> Cc: Sven Meier >> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 >> >> The problem seems to be caused by >> http://issues.apache.org/jira/**browse/WICKET-5164<http://issues.apache.org/jira/browse/WICKET-5164> >> With this change any kind of attribute added to the http session causes >> total removal of all data from the disk store. >> This looks quite serious. >> >> @Sven: can you take a look. >> >> >> On Thu, Sep 26, 2013 at 10:30 PM, Paul Bors wrote: >> >> Hey Martin, >>> >>> >>> >>> So I put in my breakpoint and it looks like that my page store is >>> always empty, is always being invalidated by two repeated stack traces >>> that come in the following order: >>> >>> >>> >>> http-thread-pool-5311(1)@8339 daemon, prio=5, in group >>> 'grizzly-kernel', >>> status: 'RUNNING' >>> >>>at >>> org.apache.wicket.pageStore.**DefaultPageStore.** >>> removePageData(DefaultPag >>> eStore.java:109) >>> >>>at >>> org.apache.wicket.pageStore.**DefaultPageStore.unbind(** >>> DefaultPageStore.j >>> ava:161) >>> >>>at >>> org.apache.wicket.page.**PageStoreManager$SessionEntry.** >>> valueUnbound(Page >>> StoreManager.java:307) >>> >>>at >>> org.apache.catalina.session.**StandardSession.setAttribute(** >>> StandardSessi >>> on.java:1738) >>> >>>at >>> org.apache.catalina.session.**StandardSessionFacade.** >>> setAttribute(Standar >>> dSessionFacade.java:178) >>> >>>at >>> org.apache.wicket.session.**HttpSessionStore.setAttribute(** >>> HttpSessionSto >>> re.java:344) >>> >>>at >>> org.apache.wicket.Session.**setAttribute(Session.java:848) >>> >>>at >>> org.apache.wicket.page.**DefaultPageManagerContext.** >>> setSessionAttribute(D >>> efaultPageManagerContext.java:**99) >>> >>>at >>> org.apache.wicket.page.**RequestAdapter.**setSessionAttribute(** >>> RequestAdapt >>> er.java:89) >>> >>>at >>> org.apache.wicket.page.**PageStoreManager$** >>> PersistentRequestAdapter.getSe >>> ssionEntry(PageStoreManager.**java:378) >>> >>>at >>> org.apache.wicket.page.**PageStoreManager$** >>> PersistentRequestAdapter.getPa >>> ge(PageStoreManager.java:349) >>> >>>at >>> org.apache.w
Re: Bunch of Page Expired exceptions in Wicket 6.10.0
Hi, >With this change any kind of attribute added to the http session causes total removal a HttpSessionBindingListener listens to removal of itself only. Any other session attribute is irrelevant. It seems an existing sessionEntry is replaced with a new one: org.apache.wicket.page.PageStoreManager$SessionEntry.valueUnbound(PageStoreManager.java:307) at ... org.apache.wicket.page.RequestAdapter.setSessionAttribute(RequestAdapter.java:89) at org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getSessionEntry(PageStoreManager.java:378) The question is why the request adapter does not find the existing sessionEntry although it is already there (and then replaced afterwards). A quickstart would help to narrow down the problem. Sven On 09/26/2013 11:46 PM, Paul Bors wrote: By rolling back to Wicket 6.9.0 I can confirm that the PageStoreManager works and I do see my page store content via DiskStoreBrowserPage. For a bit more environmental details, I was running my tests on top of GlassFish 3.1.2.2 Thanks for the heads up Martin! For now I'll stick to 6.9.x :) ~ Thank you, Paul Bors -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Thursday, September 26, 2013 5:01 PM To: users@wicket.apache.org Cc: Sven Meier Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 The problem seems to be caused by http://issues.apache.org/jira/browse/WICKET-5164 With this change any kind of attribute added to the http session causes total removal of all data from the disk store. This looks quite serious. @Sven: can you take a look. On Thu, Sep 26, 2013 at 10:30 PM, Paul Bors wrote: Hey Martin, So I put in my breakpoint and it looks like that my page store is always empty, is always being invalidated by two repeated stack traces that come in the following order: http-thread-pool-5311(1)@8339 daemon, prio=5, in group 'grizzly-kernel', status: 'RUNNING' at org.apache.wicket.pageStore.DefaultPageStore.removePageData(DefaultPag eStore.java:109) at org.apache.wicket.pageStore.DefaultPageStore.unbind(DefaultPageStore.j ava:161) at org.apache.wicket.page.PageStoreManager$SessionEntry.valueUnbound(Page StoreManager.java:307) at org.apache.catalina.session.StandardSession.setAttribute(StandardSessi on.java:1738) at org.apache.catalina.session.StandardSessionFacade.setAttribute(Standar dSessionFacade.java:178) at org.apache.wicket.session.HttpSessionStore.setAttribute(HttpSessionSto re.java:344) at org.apache.wicket.Session.setAttribute(Session.java:848) at org.apache.wicket.page.DefaultPageManagerContext.setSessionAttribute(D efaultPageManagerContext.java:99) at org.apache.wicket.page.RequestAdapter.setSessionAttribute(RequestAdapt er.java:89) at org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getSe ssionEntry(PageStoreManager.java:378) at org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPa ge(PageStoreManager.java:349) at org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager .java:107) at org.apache.wicket.page.PageManagerDecorator.getPage(PageManagerDecorat or.java:52) at org.apache.wicket.page.PageAccessSynchronizer$2.getPage(PageAccessSync hronizer.java:257) at org.apache.wicket.DefaultMapperContext.getPageInstance(DefaultMapperCo ntext.java:148) at org.apache.wicket.core.request.handler.PageProvider.getStoredPage(Page Provider.java:296) at org.apache.wicket.core.request.handler.PageProvider.resolvePageInstanc e(PageProvider.java:261) at org.apache.wicket.core.request.handler.PageProvider.getPageInstance(Pa geProvider.java:166) at org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler .getPage(ListenerInterfaceRequestHandler.java:96) at org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler .respond(ListenerInterfaceRequestHandler.java:157) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(R equestCycle.java:861) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerSt ack.java:64) at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java :261) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCyc le.java:218) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(R equestCycle.java:289) at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(Wicke tFilter.java
Re: Bunch of Page Expired exceptions in Wicket 6.10.0
On Fri, Sep 27, 2013 at 8:20 AM, miguel wrote: > by tabs do you mean browser tabs? > > if you have 2 tabs: > > http://localhost:8080/Foo > > and > > http://localhost:8081/Bar > > then reloading each tab will often invalidate the previous tab. the session > cookie is overwritten. > This is not correct. Browser tabs share the same http session. > > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Bunch-of-Page-Expired-exceptions-in-Wicket-6-10-0-tp4661502p4661540.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Bunch of Page Expired exceptions in Wicket 6.10.0
by tabs do you mean browser tabs? if you have 2 tabs: http://localhost:8080/Foo and http://localhost:8081/Bar then reloading each tab will often invalidate the previous tab. the session cookie is overwritten. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Bunch-of-Page-Expired-exceptions-in-Wicket-6-10-0-tp4661502p4661540.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Bunch of Page Expired exceptions in Wicket 6.10.0
By rolling back to Wicket 6.9.0 I can confirm that the PageStoreManager works and I do see my page store content via DiskStoreBrowserPage. For a bit more environmental details, I was running my tests on top of GlassFish 3.1.2.2 Thanks for the heads up Martin! For now I'll stick to 6.9.x :) ~ Thank you, Paul Bors -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Thursday, September 26, 2013 5:01 PM To: users@wicket.apache.org Cc: Sven Meier Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 The problem seems to be caused by http://issues.apache.org/jira/browse/WICKET-5164 With this change any kind of attribute added to the http session causes total removal of all data from the disk store. This looks quite serious. @Sven: can you take a look. On Thu, Sep 26, 2013 at 10:30 PM, Paul Bors wrote: > Hey Martin, > > > > So I put in my breakpoint and it looks like that my page store is > always empty, is always being invalidated by two repeated stack traces > that come in the following order: > > > > http-thread-pool-5311(1)@8339 daemon, prio=5, in group > 'grizzly-kernel', > status: 'RUNNING' > > at > org.apache.wicket.pageStore.DefaultPageStore.removePageData(DefaultPag > eStore.java:109) > > at > org.apache.wicket.pageStore.DefaultPageStore.unbind(DefaultPageStore.j > ava:161) > > at > org.apache.wicket.page.PageStoreManager$SessionEntry.valueUnbound(Page > StoreManager.java:307) > > at > org.apache.catalina.session.StandardSession.setAttribute(StandardSessi > on.java:1738) > > at > org.apache.catalina.session.StandardSessionFacade.setAttribute(Standar > dSessionFacade.java:178) > > at > org.apache.wicket.session.HttpSessionStore.setAttribute(HttpSessionSto > re.java:344) > > at > org.apache.wicket.Session.setAttribute(Session.java:848) > > at > org.apache.wicket.page.DefaultPageManagerContext.setSessionAttribute(D > efaultPageManagerContext.java:99) > > at > org.apache.wicket.page.RequestAdapter.setSessionAttribute(RequestAdapt > er.java:89) > > at > org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getSe > ssionEntry(PageStoreManager.java:378) > > at > org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPa > ge(PageStoreManager.java:349) > > at > org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager > .java:107) > > at > org.apache.wicket.page.PageManagerDecorator.getPage(PageManagerDecorat > or.java:52) > > at > org.apache.wicket.page.PageAccessSynchronizer$2.getPage(PageAccessSync > hronizer.java:257) > > at > org.apache.wicket.DefaultMapperContext.getPageInstance(DefaultMapperCo > ntext.java:148) > > at > org.apache.wicket.core.request.handler.PageProvider.getStoredPage(Page > Provider.java:296) > > at > org.apache.wicket.core.request.handler.PageProvider.resolvePageInstanc > e(PageProvider.java:261) > > at > org.apache.wicket.core.request.handler.PageProvider.getPageInstance(Pa > geProvider.java:166) > > at > org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler > .getPage(ListenerInterfaceRequestHandler.java:96) > > at > org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler > .respond(ListenerInterfaceRequestHandler.java:157) > > at > org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(R > equestCycle.java:861) > > at > org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerSt > ack.java:64) > > at > org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java > :261) > > at > org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCyc > le.java:218) > > at > org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(R > equestCycle.java:289) > > at > org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(Wicke > tFilter.java:259) > > at > org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilt > er.java:201) > > at > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.jav > a:282) > > > > Fallowed by: > > > > http-thread-pool-5311(
Re: Bunch of Page Expired exceptions in Wicket 6.10.0
gt; org.apache.wicket.session.HttpSessionStore.setAttribute(HttpSessionStore.java:344) > > at > org.apache.wicket.Session.setAttribute(Session.java:848) > > at > org.apache.wicket.page.DefaultPageManagerContext.setSessionAttribute(DefaultPageManagerContext.java:99) > > at > org.apache.wicket.page.RequestAdapter.setSessionAttribute(RequestAdapter.java:89) > > at > org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getSessionEntry(PageStoreManager.java:378) > > at > org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.storeTouchedPages(PageStoreManager.java:405) > > at > org.apache.wicket.page.RequestAdapter.commitRequest(RequestAdapter.java:181) > > at > org.apache.wicket.page.AbstractPageManager.commitRequest(AbstractPageManager.java:98) > > at > org.apache.wicket.page.PageManagerDecorator.commitRequest(PageManagerDecorator.java:73) > > at > org.apache.wicket.page.PageAccessSynchronizer$2.commitRequest(PageAccessSynchronizer.java:281) > > at > org.apache.wicket.Application$2.onDetach(Application.java:1628) > > at > org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:105) > > at > org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:101) > > at > org.apache.wicket.util.listener.ListenerCollection$1.notify(ListenerCollection.java:120) > > at > org.apache.wicket.util.listener.ListenerCollection.reversedNotify(ListenerCollection.java:144) > > at > org.apache.wicket.util.listener.ListenerCollection.reversedNotifyIgnoringExceptions(ListenerCollection.java:113) > > at > org.apache.wicket.request.cycle.RequestCycleListenerCollection.onDetach(RequestCycleListenerCollection.java:100) > > at > org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:640) > > at > org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:589) > > at > org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293) > > at > org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259) > > at > org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) > > at > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282) > > > > This happens for each page request and as soon as a form is submitted the > back button redirects the user to the page expired for good reason (page > store is empty). > > > > I also noticed that the work done for WICKET-3865 is not registering the > DebugPageManagerProvider which I added inside my init’s method via: > > setPageManagerProvider(new > DebugPageManagerProvider(WicketApplication.this)); > > > > Please advise. > > > > From: Martin Grigorov [mailto:mgrigo...@apache.org] > Sent: Thursday, September 26, 2013 3:13 AM > To: users@wicket.apache.org > Cc: Paul Bors > Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 > > > > Hi, > > > > DEBUG: 09/25 17:35:40.956: PageAccessSynchronizer: http-thread-pool-5311(4) > acquired lock to page 53 > > DEBUG: 09/25 17:35:40.957: DiskDataStore: Removing data for pages in > session > with id '702b17085b39e8a599d07e81df51' > > DEBUG: 09/25 17:35:40.960: DiskDataStore: Returning data(null) for page > with > id '53' in session with id '702b17085b39e8a599d07e81df51' > > > > > > The second log leads to the problem. It seems the session is invalidated... > > Put a breakpoint at > org.apache.wicket.pageStore.DefaultPageStore#removePageData and see who > calls it. > > > > On Thu, Sep 26, 2013 at 5:04 AM, Paul Borș wrote: > > I think I found my answer here: > https://cwiki.apache.org/confluence/display/WICKET/Page+Storage > > I'll grab the Wicket sources tomorrow and hook my IntelliJ IDEA debugger > to the DiskDataStore and work it backwards to see what happens. > > Stay tuned... ;) > > Have a great day, > Paul Bors > > > > On Sep 25, 2013, at 5:59 PM, Paul Bors wrote: > > > > Hey guys, > > > > Just wondering what could be the cause of the many page expired > exceptions I am running into with this webapp whenever the user changes > tabs and then sele
RE: Bunch of Page Expired exceptions in Wicket 6.10.0
ommitRequest(AbstractPageManager.java:98) at org.apache.wicket.page.PageManagerDecorator.commitRequest(PageManagerDecorator.java:73) at org.apache.wicket.page.PageAccessSynchronizer$2.commitRequest(PageAccessSynchronizer.java:281) at org.apache.wicket.Application$2.onDetach(Application.java:1628) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:105) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:101) at org.apache.wicket.util.listener.ListenerCollection$1.notify(ListenerCollection.java:120) at org.apache.wicket.util.listener.ListenerCollection.reversedNotify(ListenerCollection.java:144) at org.apache.wicket.util.listener.ListenerCollection.reversedNotifyIgnoringExceptions(ListenerCollection.java:113) at org.apache.wicket.request.cycle.RequestCycleListenerCollection.onDetach(RequestCycleListenerCollection.java:100) at org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:640) at org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:589) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293) at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282) This happens for each page request and as soon as a form is submitted the back button redirects the user to the page expired for good reason (page store is empty). I also noticed that the work done for WICKET-3865 is not registering the DebugPageManagerProvider which I added inside my init’s method via: setPageManagerProvider(new DebugPageManagerProvider(WicketApplication.this)); Please advise. From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Thursday, September 26, 2013 3:13 AM To: users@wicket.apache.org Cc: Paul Bors Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 Hi, DEBUG: 09/25 17:35:40.956: PageAccessSynchronizer: http-thread-pool-5311(4) acquired lock to page 53 DEBUG: 09/25 17:35:40.957: DiskDataStore: Removing data for pages in session with id '702b17085b39e8a599d07e81df51' DEBUG: 09/25 17:35:40.960: DiskDataStore: Returning data(null) for page with id '53' in session with id '702b17085b39e8a599d07e81df51' The second log leads to the problem. It seems the session is invalidated... Put a breakpoint at org.apache.wicket.pageStore.DefaultPageStore#removePageData and see who calls it. On Thu, Sep 26, 2013 at 5:04 AM, Paul Borș wrote: I think I found my answer here: https://cwiki.apache.org/confluence/display/WICKET/Page+Storage I'll grab the Wicket sources tomorrow and hook my IntelliJ IDEA debugger to the DiskDataStore and work it backwards to see what happens. Stay tuned... ;) Have a great day, Paul Bors > On Sep 25, 2013, at 5:59 PM, Paul Bors wrote: > > Hey guys, > > Just wondering what could be the cause of the many page expired exceptions I > am running into with this webapp whenever the user changes tabs and then > selects the browser’s “Back” button or whenever the user downloads a resource > via a button and the form is being submitted a second time. > > My first guess is that the page might have issues with its stateless flags > but help is welcomed as I’m still new to Wicket 6.x. > > If needed I can create a quick-start. > > The following is an example of the log right after the button has been hit a > second time to submit the form: > > DEBUG: 09/25 17:35:40.954: ServletWebRequest: Calculating context relative > path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' > DEBUG: 09/25 17:35:40.955: ServletWebRequest: Calculating context relative > path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' > DEBUG: 09/25 17:35:40.955: ServletWebRequest: Calculating context relative > path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' > DEBUG: 09/25 17:35:40.956: CompoundRequestMapper: One compatible mapper found > for URL 'wicket/page?53-1.IFormSubmitListener-exportForm' -> 'Mapper: > org.apache.wicket.core.request.mapper.PageInstanceMapper; Score: 2147483647' > DEBUG: 09/25 17:35:40.956: ServletWebRequest: Calculating context relative > path from: context path '', filterPrefix 'app/
Re: Bunch of Page Expired exceptions in Wicket 6.10.0
Hi, DEBUG: 09/25 17:35:40.956: PageAccessSynchronizer: http-thread-pool-5311(4) acquired lock to page 53 DEBUG: 09/25 17:35:40.957: DiskDataStore: Removing data for pages in session with id '702b17085b39e8a599d07e81df51' DEBUG: 09/25 17:35:40.960: DiskDataStore: Returning data(null) for page with id '53' in session with id '702b17085b39e8a599d07e81df51' The second log leads to the problem. It seems the session is invalidated... Put a breakpoint at org.apache.wicket.pageStore.DefaultPageStore#removePageData and see who calls it. On Thu, Sep 26, 2013 at 5:04 AM, Paul Borș wrote: > I think I found my answer here: > https://cwiki.apache.org/confluence/display/WICKET/Page+Storage > > I'll grab the Wicket sources tomorrow and hook my IntelliJ IDEA debugger > to the DiskDataStore and work it backwards to see what happens. > > Stay tuned... ;) > > Have a great day, > Paul Bors > > > On Sep 25, 2013, at 5:59 PM, Paul Bors wrote: > > > > Hey guys, > > > > Just wondering what could be the cause of the many page expired > exceptions I am running into with this webapp whenever the user changes > tabs and then selects the browser’s “Back” button or whenever the user > downloads a resource via a button and the form is being submitted a second > time. > > > > My first guess is that the page might have issues with its stateless > flags but help is welcomed as I’m still new to Wicket 6.x. > > > > If needed I can create a quick-start. > > > > The following is an example of the log right after the button has been > hit a second time to submit the form: > > > > DEBUG: 09/25 17:35:40.954: ServletWebRequest: Calculating context > relative path from: context path '', filterPrefix 'app/', uri > '/app/wicket/page' > > DEBUG: 09/25 17:35:40.955: ServletWebRequest: Calculating context > relative path from: context path '', filterPrefix 'app/', uri > '/app/wicket/page' > > DEBUG: 09/25 17:35:40.955: ServletWebRequest: Calculating context > relative path from: context path '', filterPrefix 'app/', uri > '/app/wicket/page' > > DEBUG: 09/25 17:35:40.956: CompoundRequestMapper: One compatible mapper > found for URL 'wicket/page?53-1.IFormSubmitListener-exportForm' -> 'Mapper: > org.apache.wicket.core.request.mapper.PageInstanceMapper; Score: 2147483647' > > DEBUG: 09/25 17:35:40.956: ServletWebRequest: Calculating context > relative path from: context path '', filterPrefix 'app/', uri > '/app/wicket/page' > > DEBUG: 09/25 17:35:40.956: PageAccessSynchronizer: > 'http-thread-pool-5311(4)' attempting to acquire lock to page with id '53' > > DEBUG: 09/25 17:35:40.956: PageAccessSynchronizer: > http-thread-pool-5311(4) acquired lock to page 53 > > DEBUG: 09/25 17:35:40.957: DiskDataStore: Removing data for pages in > session with id '702b17085b39e8a599d07e81df51' > > DEBUG: 09/25 17:35:40.960: DiskDataStore: Returning data(null) for page > with id '53' in session with id '702b17085b39e8a599d07e81df51' > > DEBUG: 09/25 17:35:40.960: AsynchronousDataStore: Returning the data of > a stored entry with sessionId '702b17085b39e8a599d07e81df51' and pageId '53' > > DEBUG: 09/25 17:35:40.961: PageAccessSynchronizer: > 'http-thread-pool-5311(4)' released lock to page with id '53' > > DEBUG: 09/25 17:35:40.961: PageAccessSynchronizer: > 'http-thread-pool-5311(4)' notifying blocked threads > > DEBUG: 09/25 17:35:40.961: ServletWebRequest: Calculating context > relative path from: context path '', filterPrefix 'app/', uri > '/app/wicket/page' > > DEBUG: 09/25 17:35:40.964: PageAccessSynchronizer: > 'http-thread-pool-5311(4)' attempting to acquire lock to page with id '55' > > DEBUG: 09/25 17:35:40.964: PageAccessSynchronizer: > http-thread-pool-5311(4) acquired lock to page 55 > > DEBUG: 09/25 17:35:40.966: MarkupContainer: Add homePageLink to [Page > class = org.apache.wicket.markup.html.pages.PageExpiredErrorPage, id = 55, > render count = 0] > > DEBUG: 09/25 17:35:40.966: Component: Begin render [Page class = > org.apache.wicket.markup.html.pages.PageExpiredErrorPage, id = 55, render > count = 1] > > DEBUG: 09/25 17:35:40.967: MarkupContainer: Add _header_0 to [Page class > = org.apache.wicket.markup.html.pages.PageExpiredErrorPage, id = 55, render > count = 1] > > DEBUG: 09/25 17:35:40.967: Component: Begin render [HtmlHeaderContainer > [Component id = _header_0]] > > DEBUG: 09/25 17:35:40.967: Component: renderHead: [BookmarkablePageLink > [Component id = homePageLink]] > > DEBUG: 09/25 17:35:40.967: Component: renderHead: [HtmlHeaderContainer > [Component id = _header_0]] > > DEBUG: 09/25 17:35:40.967: Component: renderHead: [PageExpiredErrorPage > [Component id = 55]] > > DEBUG: 09/25 17:35:40.968: Component: End render [HtmlHeaderContainer > [Component id = _header_0]] > > DEBUG: 09/25 17:35:40.968: Component: Begin render [BookmarkablePageLink > [Component id = homePageLink]] > > DEBUG: 09/25 17:35:40.969: ServletWebRequest: Calculating context > relative path from: context path '', filterPrefix 'app/', uri > '/app/wicket/page' > >
Re: Bunch of Page Expired exceptions in Wicket 6.10.0
I think I found my answer here: https://cwiki.apache.org/confluence/display/WICKET/Page+Storage I'll grab the Wicket sources tomorrow and hook my IntelliJ IDEA debugger to the DiskDataStore and work it backwards to see what happens. Stay tuned... ;) Have a great day, Paul Bors > On Sep 25, 2013, at 5:59 PM, Paul Bors wrote: > > Hey guys, > > Just wondering what could be the cause of the many page expired exceptions I > am running into with this webapp whenever the user changes tabs and then > selects the browser’s “Back” button or whenever the user downloads a resource > via a button and the form is being submitted a second time. > > My first guess is that the page might have issues with its stateless flags > but help is welcomed as I’m still new to Wicket 6.x. > > If needed I can create a quick-start. > > The following is an example of the log right after the button has been hit a > second time to submit the form: > > DEBUG: 09/25 17:35:40.954: ServletWebRequest: Calculating context relative > path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' > DEBUG: 09/25 17:35:40.955: ServletWebRequest: Calculating context relative > path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' > DEBUG: 09/25 17:35:40.955: ServletWebRequest: Calculating context relative > path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' > DEBUG: 09/25 17:35:40.956: CompoundRequestMapper: One compatible mapper found > for URL 'wicket/page?53-1.IFormSubmitListener-exportForm' -> 'Mapper: > org.apache.wicket.core.request.mapper.PageInstanceMapper; Score: 2147483647' > DEBUG: 09/25 17:35:40.956: ServletWebRequest: Calculating context relative > path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' > DEBUG: 09/25 17:35:40.956: PageAccessSynchronizer: 'http-thread-pool-5311(4)' > attempting to acquire lock to page with id '53' > DEBUG: 09/25 17:35:40.956: PageAccessSynchronizer: http-thread-pool-5311(4) > acquired lock to page 53 > DEBUG: 09/25 17:35:40.957: DiskDataStore: Removing data for pages in session > with id '702b17085b39e8a599d07e81df51' > DEBUG: 09/25 17:35:40.960: DiskDataStore: Returning data(null) for page with > id '53' in session with id '702b17085b39e8a599d07e81df51' > DEBUG: 09/25 17:35:40.960: AsynchronousDataStore: Returning the data of a > stored entry with sessionId '702b17085b39e8a599d07e81df51' and pageId '53' > DEBUG: 09/25 17:35:40.961: PageAccessSynchronizer: 'http-thread-pool-5311(4)' > released lock to page with id '53' > DEBUG: 09/25 17:35:40.961: PageAccessSynchronizer: 'http-thread-pool-5311(4)' > notifying blocked threads > DEBUG: 09/25 17:35:40.961: ServletWebRequest: Calculating context relative > path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' > DEBUG: 09/25 17:35:40.964: PageAccessSynchronizer: 'http-thread-pool-5311(4)' > attempting to acquire lock to page with id '55' > DEBUG: 09/25 17:35:40.964: PageAccessSynchronizer: http-thread-pool-5311(4) > acquired lock to page 55 > DEBUG: 09/25 17:35:40.966: MarkupContainer: Add homePageLink to [Page class = > org.apache.wicket.markup.html.pages.PageExpiredErrorPage, id = 55, render > count = 0] > DEBUG: 09/25 17:35:40.966: Component: Begin render [Page class = > org.apache.wicket.markup.html.pages.PageExpiredErrorPage, id = 55, render > count = 1] > DEBUG: 09/25 17:35:40.967: MarkupContainer: Add _header_0 to [Page class = > org.apache.wicket.markup.html.pages.PageExpiredErrorPage, id = 55, render > count = 1] > DEBUG: 09/25 17:35:40.967: Component: Begin render [HtmlHeaderContainer > [Component id = _header_0]] > DEBUG: 09/25 17:35:40.967: Component: renderHead: [BookmarkablePageLink > [Component id = homePageLink]] > DEBUG: 09/25 17:35:40.967: Component: renderHead: [HtmlHeaderContainer > [Component id = _header_0]] > DEBUG: 09/25 17:35:40.967: Component: renderHead: [PageExpiredErrorPage > [Component id = 55]] > DEBUG: 09/25 17:35:40.968: Component: End render [HtmlHeaderContainer > [Component id = _header_0]] > DEBUG: 09/25 17:35:40.968: Component: Begin render [BookmarkablePageLink > [Component id = homePageLink]] > DEBUG: 09/25 17:35:40.969: ServletWebRequest: Calculating context relative > path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' > DEBUG: 09/25 17:35:40.970: ServletWebRequest: Calculating context relative > path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' > DEBUG: 09/25 17:35:40.970: ServletWebRequest: Calculating context relative > path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' > DEBUG: 09/25 17:35:40.970: ServletWebRequest: Calculating context relative > path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' > DEBUG: 09/25 17:35:40.971: Component: End render [BookmarkablePageLink > [Component id = homePageLink]] > DEBUG: 09/25 17:35:40.971: Component: End render [Page class = > org.apache.wicket.markup.h
Bunch of Page Expired exceptions in Wicket 6.10.0
Hey guys, Just wondering what could be the cause of the many page expired exceptions I am running into with this webapp whenever the user changes tabs and then selects the browser's "Back" button or whenever the user downloads a resource via a button and the form is being submitted a second time. My first guess is that the page might have issues with its stateless flags but help is welcomed as I'm still new to Wicket 6.x. If needed I can create a quick-start. The following is an example of the log right after the button has been hit a second time to submit the form: DEBUG: 09/25 17:35:40.954: ServletWebRequest: Calculating context relative path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' DEBUG: 09/25 17:35:40.955: ServletWebRequest: Calculating context relative path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' DEBUG: 09/25 17:35:40.955: ServletWebRequest: Calculating context relative path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' DEBUG: 09/25 17:35:40.956: CompoundRequestMapper: One compatible mapper found for URL 'wicket/page?53-1.IFormSubmitListener-exportForm' -> 'Mapper: org.apache.wicket.core.request.mapper.PageInstanceMapper; Score: 2147483647' DEBUG: 09/25 17:35:40.956: ServletWebRequest: Calculating context relative path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' DEBUG: 09/25 17:35:40.956: PageAccessSynchronizer: 'http-thread-pool-5311(4)' attempting to acquire lock to page with id '53' DEBUG: 09/25 17:35:40.956: PageAccessSynchronizer: http-thread-pool-5311(4) acquired lock to page 53 DEBUG: 09/25 17:35:40.957: DiskDataStore: Removing data for pages in session with id '702b17085b39e8a599d07e81df51' DEBUG: 09/25 17:35:40.960: DiskDataStore: Returning data(null) for page with id '53' in session with id '702b17085b39e8a599d07e81df51' DEBUG: 09/25 17:35:40.960: AsynchronousDataStore: Returning the data of a stored entry with sessionId '702b17085b39e8a599d07e81df51' and pageId '53' DEBUG: 09/25 17:35:40.961: PageAccessSynchronizer: 'http-thread-pool-5311(4)' released lock to page with id '53' DEBUG: 09/25 17:35:40.961: PageAccessSynchronizer: 'http-thread-pool-5311(4)' notifying blocked threads DEBUG: 09/25 17:35:40.961: ServletWebRequest: Calculating context relative path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' DEBUG: 09/25 17:35:40.964: PageAccessSynchronizer: 'http-thread-pool-5311(4)' attempting to acquire lock to page with id '55' DEBUG: 09/25 17:35:40.964: PageAccessSynchronizer: http-thread-pool-5311(4) acquired lock to page 55 DEBUG: 09/25 17:35:40.966: MarkupContainer: Add homePageLink to [Page class = org.apache.wicket.markup.html.pages.PageExpiredErrorPage, id = 55, render count = 0] DEBUG: 09/25 17:35:40.966: Component: Begin render [Page class = org.apache.wicket.markup.html.pages.PageExpiredErrorPage, id = 55, render count = 1] DEBUG: 09/25 17:35:40.967: MarkupContainer: Add _header_0 to [Page class = org.apache.wicket.markup.html.pages.PageExpiredErrorPage, id = 55, render count = 1] DEBUG: 09/25 17:35:40.967: Component: Begin render [HtmlHeaderContainer [Component id = _header_0]] DEBUG: 09/25 17:35:40.967: Component: renderHead: [BookmarkablePageLink [Component id = homePageLink]] DEBUG: 09/25 17:35:40.967: Component: renderHead: [HtmlHeaderContainer [Component id = _header_0]] DEBUG: 09/25 17:35:40.967: Component: renderHead: [PageExpiredErrorPage [Component id = 55]] DEBUG: 09/25 17:35:40.968: Component: End render [HtmlHeaderContainer [Component id = _header_0]] DEBUG: 09/25 17:35:40.968: Component: Begin render [BookmarkablePageLink [Component id = homePageLink]] DEBUG: 09/25 17:35:40.969: ServletWebRequest: Calculating context relative path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' DEBUG: 09/25 17:35:40.970: ServletWebRequest: Calculating context relative path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' DEBUG: 09/25 17:35:40.970: ServletWebRequest: Calculating context relative path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' DEBUG: 09/25 17:35:40.970: ServletWebRequest: Calculating context relative path from: context path '', filterPrefix 'app/', uri '/app/wicket/page' DEBUG: 09/25 17:35:40.971: Component: End render [BookmarkablePageLink [Component id = homePageLink]] DEBUG: 09/25 17:35:40.971: Component: End render [Page class = org.apache.wicket.markup.html.pages.PageExpiredErrorPage, id = 55, render count = 1] DEBUG: 09/25 17:35:40.971: PageAccessSynchronizer: 'http-thread-pool-5311(4)' attempting to acquire lock to page with id '53' DEBUG: 09/25 17:35:40.971: PageAccessSynchronizer: http-thread-pool-5311(4) acquired lock to page 53 DEBUG: 09/25 17:35:40.972: DiskDataStore: Returning data(null) for page with id '53' in session with id '702b17085b39e8a599d07e81df51' DEBUG: 09/25 17:35:40.972: AsynchronousDataStore: Returning the data of