You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Paul Bors <pa...@bors.ws> on 2013/09/27 18:27:25 UTC
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:paul@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:mgrigorov@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 <sv...@meiers.net> 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 <sv...@meiers.net> 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:mgrigorov@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 <pa...@bors.ws> 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.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(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.store
>>>>> TouchedPages(PageStoreManager.****java:405)
>>>>>
>>>>> at
>>>>> org.apache.wicket.page.****RequestAdapter.commitRequest(****
>>>>> RequestAdapter.jav
>>>>> a:181)
>>>>>
>>>>> at
>>>>> org.apache.wicket.page.****AbstractPageManager.**
>>>>> commitRequest(AbstractPageM
>>>>> anager.java:98)
>>>>>
>>>>> at
>>>>> org.apache.wicket.page.****PageManagerDecorator.**
>>>>> commitRequest(PageManagerD
>>>>> ecorator.java:73)
>>>>>
>>>>> at
>>>>> org.apache.wicket.page.****PageAccessSynchronizer$2.**
>>>>> commitRequest(PageAcce
>>>>> ssSynchronizer.java:281)
>>>>>
>>>>> at
>>>>> org.apache.wicket.Application$****2.onDetach(Application.java:**
>>>>> **1628)
>>>>>
>>>>> at
>>>>> org.apache.wicket.request.****cycle.****RequestCycleListenerCollec
>>>>> tion
>>>>> ****
>>>>> $3.notif
>>>>> y(****RequestCycleListenerCollection****.java:105)
>>>>>
>>>>> at
>>>>> org.apache.wicket.request.****cycle.****RequestCycleListenerCollec
>>>>> tion
>>>>> ****
>>>>> $3.notif
>>>>> y(****RequestCycleListenerCollection****.java:101)
>>>>>
>>>>> at
>>>>> org.apache.wicket.util.****listener.ListenerCollection$1.****
>>>>> notify(ListenerCo
>>>>> llection.java:120)
>>>>>
>>>>> at
>>>>> org.apache.wicket.util.****listener.ListenerCollection.**
>>>>> reversedNotify(List
>>>>> enerCollection.java:144)
>>>>>
>>>>> at
>>>>> org.apache.wicket.util.****listener.ListenerCollection.**
>>>>> reversedNotifyIgnor
>>>>> ingExceptions(****ListenerCollection.java:113)
>>>>>
>>>>> at
>>>>> org.apache.wicket.request.****cycle.****RequestCycleListenerCollec
>>>>> tion
>>>>> ****
>>>>> .onDetac
>>>>> h(****RequestCycleListenerCollection****.java:100)
>>>>>
>>>>> at
>>>>> org.apache.wicket.request.****cycle.RequestCycle.onDetach(**
>>>>> RequestCycle.jav
>>>>> a:640)
>>>>>
>>>>> at
>>>>> org.apache.wicket.request.****cycle.RequestCycle.detach(**
>>>>> RequestCycle.java:
>>>>> 589)
>>>>>
>>>>> at
>>>>> org.apache.wicket.request.****cycle.RequestCycle.**
>>>>> processRequestAndDetach(R
>>>>> equestCycle.java:293)
>>>>>
>>>>> 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)
>>>>>
>>>>>
>>>>>
>>>>> 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:mgrigorov@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#****removePageDat
>>>>> a
>>>>> and see
>>>>>
>>>>> who calls it.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 26, 2013 at 5:04 AM, Paul Borș <pa...@bors.ws> wrote:
>>>>>
>>>>> I think I found my answer here:
>>>>> https://cwiki.apache.org/****confluence/display/WICKET/****
>>>>> Page+Storage<https://cwiki.apache.org/**confluence/display/WICKET/
>>>>> Page+**Page+Storage>
>>>>> <https://cwiki.**apache.org/confluence/display/**WICKET/Page+Stora
>>>>> ge<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 <pa...@bors.ws> 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.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
>>>>>>
>>>>>> a stored entry with sessionId '702b17085b39e8a599d07e81df51' and
>>>>> pageId
>>>>> '53'
>>>>>
>>>>> DEBUG: 09/25 17:35:40.972: PageAccessSynchronizer:
>>>>>>
>>>>>> 'http-thread-pool-5311(4)' released lock to page with id '53'
>>>>>
>>>>> DEBUG: 09/25 17:35:40.972: PageAccessSynchronizer:
>>>>>>
>>>>>> 'http-thread-pool-5311(4)' notifying blocked threads
>>>>>
>>>>> DEBUG: 09/25 17:35:40.972: PageAccessSynchronizer:
>>>>>>
>>>>>> 'http-thread-pool-5311(4)' attempting to acquire lock to page
>>>>>> with id
>>>>> '53'
>>>>>
>>>>> DEBUG: 09/25 17:35:40.972: PageAccessSynchronizer:
>>>>>>
>>>>>> http-thread-pool-5311(4) acquired lock to page 53
>>>>>
>>>>> DEBUG: 09/25 17:35:40.973: DiskDataStore: Returning data(null)
>>>>> for
>>>>>> page
>>>>>>
>>>>>> with id '53' in session with id '702b17085b39e8a599d07e81df51'
>>>>>
>>>>> DEBUG: 09/25 17:35:40.973: AsynchronousDataStore: Returning the
>>>>> data
>>>>>> of
>>>>>>
>>>>>> a stored entry with sessionId '702b17085b39e8a599d07e81df51' and
>>>>> pageId
>>>>> '53'
>>>>>
>>>>> DEBUG: 09/25 17:35:40.973: PageAccessSynchronizer:
>>>>>>
>>>>>> 'http-thread-pool-5311(4)' released lock to page with id '53'
>>>>>
>>>>> DEBUG: 09/25 17:35:40.973: PageAccessSynchronizer:
>>>>>>
>>>>>> 'http-thread-pool-5311(4)' notifying blocked threads
>>>>>
>>>>> DEBUG: 09/25 17:35:40.973: PageAccessSynchronizer:
>>>>>>
>>>>>> 'http-thread-pool-5311(4)' attempting to acquire lock to page
>>>>>> with id
>>>>> '53'
>>>>>
>>>>> DEBUG: 09/25 17:35:40.973: PageAccessSynchronizer:
>>>>>>
>>>>>> http-thread-pool-5311(4) acquired lock to page 53
>>>>>
>>>>> DEBUG: 09/25 17:35:40.974: DiskDataStore: Returning data(null)
>>>>> for
>>>>>> page
>>>>>>
>>>>>> with id '53' in session with id '702b17085b39e8a599d07e81df51'
>>>>>
>>>>> DEBUG: 09/25 17:35:40.974: AsynchronousDataStore: Returning the
>>>>> data
>>>>>> of
>>>>>>
>>>>>> a stored entry with sessionId '702b17085b39e8a599d07e81df51' and
>>>>> pageId
>>>>> '53'
>>>>>
>>>>> DEBUG: 09/25 17:35:40.974: PageAccessSynchronizer:
>>>>>>
>>>>>> 'http-thread-pool-5311(4)' released lock to page with id '53'
>>>>>
>>>>> DEBUG: 09/25 17:35:40.974: PageAccessSynchronizer:
>>>>>>
>>>>>> 'http-thread-pool-5311(4)' notifying blocked threads
>>>>>
>>>>> DEBUG: 09/25 17:35:40.974: PageAccessSynchronizer:
>>>>>>
>>>>>> 'http-thread-pool-5311(4)' attempting to acquire lock to page
>>>>>> with id
>>>>> '53'
>>>>>
>>>>> DEBUG: 09/25 17:35:40.974: PageAccessSynchronizer:
>>>>>>
>>>>>> http-thread-pool-5311(4) acquired lock to page 53
>>>>>
>>>>> DEBUG: 09/25 17:35:40.975: DiskDataStore: Returning data(null)
>>>>> for
>>>>>> page
>>>>>>
>>>>>> with id '53' in session with id '702b17085b39e8a599d07e81df51'
>>>>>
>>>>> DEBUG: 09/25 17:35:40.975: AsynchronousDataStore: Returning the
>>>>> data
>>>>>> of
>>>>>>
>>>>>> a stored entry with sessionId '702b17085b39e8a599d07e81df51' and
>>>>> pageId
>>>>> '53'
>>>>>
>>>>> DEBUG: 09/25 17:35:40.975: PageAccessSynchronizer:
>>>>>>
>>>>>> 'http-thread-pool-5311(4)' released lock to page with id '53'
>>>>>
>>>>> DEBUG: 09/25 17:35:40.975: PageAccessSynchronizer:
>>>>>>
>>>>>> 'http-thread-pool-5311(4)' notifying blocked threads
>>>>>
>>>>> DEBUG: 09/25 17:35:40.975: Page: ending request for page [Page
>>>>> class
>>>>>> =
>>>>>>
>>>>>> org.apache.wicket.markup.html.****pages.PageExpiredErrorPage, id
>>>>>> =
>>>>> 55,
>>>>>
>>>>> render count = 1], request
>>>>> org.apache.wicket.protocol.****http.servlet.****
>>>>> ServletWebRequest@5b454b
>>>>>
>>>>>
>>>>> DEBUG: 09/25 17:35:40.975: Page: ending request for page [Page
>>>>> class
>>>>>> =
>>>>>>
>>>>>> org.apache.wicket.markup.html.****pages.PageExpiredErrorPage, id
>>>>>> =
>>>>> 55,
>>>>>
>>>>> render count = 1], request
>>>>> org.apache.wicket.protocol.****http.servlet.****
>>>>> ServletWebRequest@5b454b
>>>>>
>>>>>
>>>>> DEBUG: 09/25 17:35:40.976: PageAccessSynchronizer:
>>>>>>
>>>>>> 'http-thread-pool-5311(4)' released lock to page with id '55'
>>>>>
>>>>> DEBUG: 09/25 17:35:40.976: PageAccessSynchronizer:
>>>>>>
>>>>>> 'http-thread-pool-5311(4)' notifying blocked threads
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------****----------------------------**
>>>> --**---------
>>>> To unsubscribe, e-mail:
>>>> users-unsubscribe@wicket.**apa**che.org<http://apache.org>
>>>> <users-unsubscribe@**wicket.apache.org<users-unsubscribe@wicket.apa
>>>> che.org>
>>>> >
>>>>
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>> ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail:
>>> users-unsubscribe@wicket.**apa**che.org<http://apache.org>
>>> <users-unsubscribe@**wicket.apache.org<users-unsubscribe@wicket.apac
>>> he.org>
>>> >
>>>
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>
> ------------------------------**------------------------------**------
> --- To unsubscribe, e-mail:
> users-unsubscribe@wicket.**apache.org<users-unsubscribe@wicket.apache.
> org> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
Posted by Paul Bors <pa...@bors.ws>.
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:mgrigorov@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 <mg...@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 <mg...@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 <mg...@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 <mg...@apache.org>wrote:
>>>
>>>> I'll test this and let you know.
>>>>
>>>>
>>>> On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors <pa...@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:mgrigorov@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 <sv...@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:paul@bors.ws]
>>>>> >> Sent: Friday, September 27, 2013 5:51 PM
>>>>> >> To: users@wicket.apache.org
>>>>> >> Cc: dev@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:mgrigorov@apache.org]
>>>>> >> Sent: Friday, September 27, 2013 4:09 PM
>>>>> >> To: users@wicket.apache.org
>>>>> >> Cc: dev@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 <pa...@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,
>>>>> >>> Paul@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-help@wicket.apache.org
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>
>>>>> >>
>>>>> ------------------------------**------------------------------**--
>>>>> ---
>>>>> >> ---- To unsubscribe, e-mail:
>>>>> >> users-unsubscribe@wicket.**apache.org
>>>>> <users-unsubscribe@wicket.apache
>>>>> >> .org> For additional commands, e-mail:
>>>>> >> users-help@wicket.apache.org
>>>>> >>
>>>>> >>
>>>>> >
>>>>> >
>>>>> ------------------------------**------------------------------**--
>>>>> ----
>>>>> > --- To unsubscribe, e-mail:
>>>>> > users-unsubscribe@wicket.**apache.org
>>>>> <users-unsubscribe@wicket.apache.
>>>>> > org> For additional commands, e-mail:
>>>>> > org> users-help@wicket.apache.org
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> --- To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3
and v4)
Posted by Martin Grigorov <mg...@apache.org>.
https://issues.apache.org/jira/browse/WICKET-5380
On Mon, Sep 30, 2013 at 12:32 PM, Martin Grigorov <mg...@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 <mg...@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 <mg...@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 <mg...@apache.org>wrote:
>>>
>>>> I'll test this and let you know.
>>>>
>>>>
>>>> On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors <pa...@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:mgrigorov@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 <sv...@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:paul@bors.ws]
>>>>> >> Sent: Friday, September 27, 2013 5:51 PM
>>>>> >> To: users@wicket.apache.org
>>>>> >> Cc: dev@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:mgrigorov@apache.org]
>>>>> >> Sent: Friday, September 27, 2013 4:09 PM
>>>>> >> To: users@wicket.apache.org
>>>>> >> Cc: dev@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 <pa...@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,
>>>>> >>> Paul@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-help@wicket.apache.org
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>
>>>>> >>
>>>>> ------------------------------**------------------------------**-----
>>>>> >> ---- To unsubscribe, e-mail:
>>>>> >> users-unsubscribe@wicket.**apache.org
>>>>> <users-unsubscribe@wicket.apache
>>>>> >> .org> For additional commands, e-mail: users-help@wicket.apache.org
>>>>> >>
>>>>> >>
>>>>> >
>>>>> >
>>>>> ------------------------------**------------------------------**------
>>>>> > --- To unsubscribe, e-mail:
>>>>> > users-unsubscribe@wicket.**apache.org
>>>>> <users-unsubscribe@wicket.apache.
>>>>> > org> For additional commands, e-mail: users-help@wicket.apache.org
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3
and v4)
Posted by Martin Grigorov <mg...@apache.org>.
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 <mg...@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 <mg...@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 <mg...@apache.org>wrote:
>>
>>> I'll test this and let you know.
>>>
>>>
>>> On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors <pa...@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:mgrigorov@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 <sv...@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:paul@bors.ws]
>>>> >> Sent: Friday, September 27, 2013 5:51 PM
>>>> >> To: users@wicket.apache.org
>>>> >> Cc: dev@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:mgrigorov@apache.org]
>>>> >> Sent: Friday, September 27, 2013 4:09 PM
>>>> >> To: users@wicket.apache.org
>>>> >> Cc: dev@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 <pa...@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,
>>>> >>> Paul@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-help@wicket.apache.org
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>
>>>> >> ------------------------------**------------------------------**-----
>>>> >> ---- To unsubscribe, e-mail:
>>>> >> users-unsubscribe@wicket.**apache.org
>>>> <users-unsubscribe@wicket.apache
>>>> >> .org> For additional commands, e-mail: users-help@wicket.apache.org
>>>> >>
>>>> >>
>>>> >
>>>> > ------------------------------**------------------------------**------
>>>> > --- To unsubscribe, e-mail:
>>>> > users-unsubscribe@wicket.**apache.org
>>>> <users-unsubscribe@wicket.apache.
>>>> > org> For additional commands, e-mail: users-help@wicket.apache.org
>>>> >
>>>> >
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>
>
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3
and v4)
Posted by Martin Grigorov <mg...@apache.org>.
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 <mg...@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 <mg...@apache.org>wrote:
>
>> I'll test this and let you know.
>>
>>
>> On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors <pa...@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:mgrigorov@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 <sv...@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:paul@bors.ws]
>>> >> Sent: Friday, September 27, 2013 5:51 PM
>>> >> To: users@wicket.apache.org
>>> >> Cc: dev@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:mgrigorov@apache.org]
>>> >> Sent: Friday, September 27, 2013 4:09 PM
>>> >> To: users@wicket.apache.org
>>> >> Cc: dev@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 <pa...@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,
>>> >>> Paul@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-help@wicket.apache.org
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >> ------------------------------**------------------------------**-----
>>> >> ---- To unsubscribe, e-mail:
>>> >> users-unsubscribe@wicket.**apache.org<users-unsubscribe@wicket.apache
>>> >> .org> For additional commands, e-mail: users-help@wicket.apache.org
>>> >>
>>> >>
>>> >
>>> > ------------------------------**------------------------------**------
>>> > --- To unsubscribe, e-mail:
>>> > users-unsubscribe@wicket.**apache.org<users-unsubscribe@wicket.apache.
>>> > org> For additional commands, e-mail: users-help@wicket.apache.org
>>> >
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3
and v4)
Posted by Martin Grigorov <mg...@apache.org>.
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 <mg...@apache.org>wrote:
> I'll test this and let you know.
>
>
> On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors <pa...@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:mgrigorov@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 <sv...@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:paul@bors.ws]
>> >> Sent: Friday, September 27, 2013 5:51 PM
>> >> To: users@wicket.apache.org
>> >> Cc: dev@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:mgrigorov@apache.org]
>> >> Sent: Friday, September 27, 2013 4:09 PM
>> >> To: users@wicket.apache.org
>> >> Cc: dev@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 <pa...@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,
>> >>> Paul@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-help@wicket.apache.org
>> >>>
>> >>>
>> >>>
>> >>
>> >> ------------------------------**------------------------------**-----
>> >> ---- To unsubscribe, e-mail:
>> >> users-unsubscribe@wicket.**apache.org<users-unsubscribe@wicket.apache
>> >> .org> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> > ------------------------------**------------------------------**------
>> > --- To unsubscribe, e-mail:
>> > users-unsubscribe@wicket.**apache.org<users-unsubscribe@wicket.apache.
>> > org> For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3
and v4)
Posted by Martin Grigorov <mg...@apache.org>.
I'll test this and let you know.
On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors <pa...@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:mgrigorov@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 <sv...@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:paul@bors.ws]
> >> Sent: Friday, September 27, 2013 5:51 PM
> >> To: users@wicket.apache.org
> >> Cc: dev@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:mgrigorov@apache.org]
> >> Sent: Friday, September 27, 2013 4:09 PM
> >> To: users@wicket.apache.org
> >> Cc: dev@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 <pa...@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,
> >>> Paul@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-help@wicket.apache.org
> >>>
> >>>
> >>>
> >>
> >> ------------------------------**------------------------------**-----
> >> ---- To unsubscribe, e-mail:
> >> users-unsubscribe@wicket.**apache.org<users-unsubscribe@wicket.apache
> >> .org> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ------------------------------**------------------------------**------
> > --- To unsubscribe, e-mail:
> > users-unsubscribe@wicket.**apache.org<users-unsubscribe@wicket.apache.
> > org> For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
RE: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
Posted by Paul Bors <pa...@bors.ws>.
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:mgrigorov@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 <sv...@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:paul@bors.ws]
>> Sent: Friday, September 27, 2013 5:51 PM
>> To: users@wicket.apache.org
>> Cc: dev@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:mgrigorov@apache.org]
>> Sent: Friday, September 27, 2013 4:09 PM
>> To: users@wicket.apache.org
>> Cc: dev@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 <pa...@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,
>>> Paul@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-help@wicket.apache.org
>>>
>>>
>>>
>>
>> ------------------------------**------------------------------**-----
>> ---- To unsubscribe, e-mail:
>> users-unsubscribe@wicket.**apache.org<users-unsubscribe@wicket.apache
>> .org> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ------------------------------**------------------------------**------
> --- To unsubscribe, e-mail:
> users-unsubscribe@wicket.**apache.org<users-unsubscribe@wicket.apache.
> org> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3
and v4)
Posted by Martin Grigorov <mg...@apache.org>.
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 <sv...@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:paul@bors.ws]
>> Sent: Friday, September 27, 2013 5:51 PM
>> To: users@wicket.apache.org
>> Cc: dev@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:mgrigorov@apache.org]
>> Sent: Friday, September 27, 2013 4:09 PM
>> To: users@wicket.apache.org
>> Cc: dev@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 <pa...@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,
>>> Paul@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<us...@wicket.apache.org>
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish
v3 and v4)
Posted by Sven Meier <sv...@meiers.net>.
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:paul@bors.ws]
> Sent: Friday, September 27, 2013 5:51 PM
> To: users@wicket.apache.org
> Cc: dev@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:mgrigorov@apache.org]
> Sent: Friday, September 27, 2013 4:09 PM
> To: users@wicket.apache.org
> Cc: dev@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 <pa...@bors.ws> 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,
>> Paul@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
Posted by Paul Bors <pa...@bors.ws>.
I take that back, the new implementation breaks the session timeout.
~ Thank you,
Paul Bors
-----Original Message-----
From: Paul Bors [mailto:paul@bors.ws]
Sent: Friday, September 27, 2013 5:51 PM
To: users@wicket.apache.org
Cc: dev@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:mgrigorov@apache.org]
Sent: Friday, September 27, 2013 4:09 PM
To: users@wicket.apache.org
Cc: dev@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 <pa...@bors.ws> 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,
> Paul@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
Posted by Paul Bors <pa...@bors.ws>.
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:mgrigorov@apache.org]
Sent: Friday, September 27, 2013 4:09 PM
To: users@wicket.apache.org
Cc: dev@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 <pa...@bors.ws> 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,
> Paul@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3
and v4)
Posted by Martin Grigorov <mg...@apache.org>.
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 <pa...@bors.ws> 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,
> Paul@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3
and v4)
Posted by Martin Grigorov <mg...@apache.org>.
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 <pa...@bors.ws> 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,
> Paul@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
RE: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3
and v4)
Posted by Paul Bors <pa...@bors.ws>.
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,
Paul@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org