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 <mgrigo...@apache.org>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 <mgrigo...@apache.org>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 >> <mgrigo...@apache.org>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 >>> <mgrigo...@apache.org>wrote: >>> >>>> I'll test this and let you know. >>>> >>>> >>>> On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors <p...@bors.ws> 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 <s...@meiers.net> 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.**PersistentRequestAdapt >>>>> er# >>>>> >> ** >>>>> >> 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 <p...@bors.ws> 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-Pa >>>>> >>> ge-Expired-excep> tions-in-Wicket-6-10-0-**tp4661502p4661582.h >>>>> >>> ge-Expired-excep> tml >>>>> >>> Sent from the Users forum mailing list archive at Nabble.com. >>>>> >>> >>>>> >>> ------------------------------**------------------------------ >>>>> >>> ** >>>>> >>> --------- >>>>> >>> To unsubscribe, e-mail: >>>>> >>> users-unsubscribe@wicket.**apache.org >>>>> <users-unsubscribe@wicket.apach >>>>> >>> e.org> For additional commands, e-mail: >>>>> users-h...@wicket.apache.org >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >> >>>>> >> >>>>> ------------------------------**------------------------------**-- >>>>> --- >>>>> >> ---- To unsubscribe, e-mail: >>>>> >> users-unsubscribe@wicket.**apache.org >>>>> <users-unsubscribe@wicket.apache >>>>> >> .org> For additional commands, e-mail: >>>>> >> users-h...@wicket.apache.org >>>>> >> >>>>> >> >>>>> > >>>>> > >>>>> ------------------------------**------------------------------**-- >>>>> ---- >>>>> > --- To unsubscribe, e-mail: >>>>> > users-unsubscribe@wicket.**apache.org >>>>> <users-unsubscribe@wicket.apache. >>>>> > org> For additional commands, e-mail: >>>>> > org> 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
