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.**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 <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.html
>> >>> 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: users-h...@wicket.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>

Reply via email to