You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Martin Grigorov <mg...@apache.org> on 2011/05/09 15:04:58 UTC
Problem with Session#invalidate()
Hi,
Since recently the RequestCycleListeners are executed in reverse order
for #onDetach() and #onException(). I.e. registered first - notified
last.
I'm facing a problem with Session#invalidate(). This method registers
a listener with #onDetach() which actually invalidates the http
session and null-ifies the Session#sessionStore.
In org.apache.wicket.Application.createRequestCycle(Request, Response)
we register a listener which executes
org.apache.wicket.page.IPageManager.commitRequest() at the end of each
request cycle. This listener is setup such way that it is always
executed as last.
The problem is:
- my app calls Session#invalidate() in a callback method (e.g. onClick())
- later when the listeners are executed Session#invalidateNow() and
Session#destroy() are called (so the http session and sessionStore are
destroyed)
- even later the special listener is executed [1] and :
-- it re-creates a new http session !
-- re-uses the same Wicket Session object. See
https://issues.apache.org/jira/browse/WICKET-3690 for a member which
leaked. But it will leak even worse if there is user impl of
WebSession with its own properties.
Am I correct in my investigations ?
1.
PersistentPageManager$PersitentRequestAdapter(RequestAdapter).bind() line: 80
PersistentPageManager$PersitentRequestAdapter.getSessionEntry(boolean)
line: 339
PersistentPageManager$PersitentRequestAdapter.storeTouchedPages(List<IManageablePage>)
line: 373
PersistentPageManager$PersitentRequestAdapter(RequestAdapter).commitRequest()
line: 185
PersistentPageManager(AbstractPageManager).commitRequest() line: 94
PageAccessSynchronizer$1(PageManagerDecorator).commitRequest() line: 68
PageAccessSynchronizer$1.commitRequest() line: 203
Application$2.onDetach(RequestCycle) line: 1522
RequestCycleListenerCollection$3.notify(IRequestCycleListener) line: 100
RequestCycleListenerCollection$3.notify(Object) line: 95
RequestCycleListenerCollection(ListenerCollection<T>).reversedNotify(Iterator<T>,
INotifier<T>) line: 121
RequestCycleListenerCollection(ListenerCollection<T>).reversedNotify(INotifier<T>)
line: 112
RequestCycleListenerCollection.onDetach(RequestCycle) line: 94
RequestCycle.onDetach() line: 547
RequestCycle.detach() line: 479
RequestCycle.processRequestAndDetach() line: 257
....
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: Problem with Session#invalidate()
Posted by Martin Grigorov <mg...@apache.org>.
r1101345
All the authen/auth tests/apps I know work with this fix.
On Mon, May 9, 2011 at 9:58 PM, Martin Grigorov <mg...@apache.org> wrote:
> Calling Session#detach() after RequestCycleListeners#onDetach() and
> not using RCL for Session#invalidate() seems to solve the problem.
> It seems even before the changes for reverse calling of RCLs there was
> this problem, because Session#detach() currently is called before
> RCLs#onDetach()
>
> On Mon, May 9, 2011 at 3:14 PM, Martin Grigorov <mg...@apache.org> wrote:
>> To make it clear: the problem is that now Session#invalidate()
>> prepends the new onDetach() listener and thus is executed before
>> commitRequest()
>>
>> On Mon, May 9, 2011 at 3:04 PM, Martin Grigorov <mg...@apache.org> wrote:
>>> Hi,
>>>
>>> Since recently the RequestCycleListeners are executed in reverse order
>>> for #onDetach() and #onException(). I.e. registered first - notified
>>> last.
>>> I'm facing a problem with Session#invalidate(). This method registers
>>> a listener with #onDetach() which actually invalidates the http
>>> session and null-ifies the Session#sessionStore.
>>> In org.apache.wicket.Application.createRequestCycle(Request, Response)
>>> we register a listener which executes
>>> org.apache.wicket.page.IPageManager.commitRequest() at the end of each
>>> request cycle. This listener is setup such way that it is always
>>> executed as last.
>>> The problem is:
>>> - my app calls Session#invalidate() in a callback method (e.g. onClick())
>>> - later when the listeners are executed Session#invalidateNow() and
>>> Session#destroy() are called (so the http session and sessionStore are
>>> destroyed)
>>> - even later the special listener is executed [1] and :
>>> -- it re-creates a new http session !
>>> -- re-uses the same Wicket Session object. See
>>> https://issues.apache.org/jira/browse/WICKET-3690 for a member which
>>> leaked. But it will leak even worse if there is user impl of
>>> WebSession with its own properties.
>>>
>>> Am I correct in my investigations ?
>>>
>>>
>>> 1.
>>> PersistentPageManager$PersitentRequestAdapter(RequestAdapter).bind() line: 80
>>> PersistentPageManager$PersitentRequestAdapter.getSessionEntry(boolean)
>>> line: 339
>>> PersistentPageManager$PersitentRequestAdapter.storeTouchedPages(List<IManageablePage>)
>>> line: 373
>>> PersistentPageManager$PersitentRequestAdapter(RequestAdapter).commitRequest()
>>> line: 185
>>> PersistentPageManager(AbstractPageManager).commitRequest() line: 94
>>> PageAccessSynchronizer$1(PageManagerDecorator).commitRequest() line: 68
>>> PageAccessSynchronizer$1.commitRequest() line: 203
>>> Application$2.onDetach(RequestCycle) line: 1522
>>> RequestCycleListenerCollection$3.notify(IRequestCycleListener) line: 100
>>> RequestCycleListenerCollection$3.notify(Object) line: 95
>>> RequestCycleListenerCollection(ListenerCollection<T>).reversedNotify(Iterator<T>,
>>> INotifier<T>) line: 121
>>> RequestCycleListenerCollection(ListenerCollection<T>).reversedNotify(INotifier<T>)
>>> line: 112
>>> RequestCycleListenerCollection.onDetach(RequestCycle) line: 94
>>> RequestCycle.onDetach() line: 547
>>> RequestCycle.detach() line: 479
>>> RequestCycle.processRequestAndDetach() line: 257
>>> ....
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: Problem with Session#invalidate()
Posted by Martin Grigorov <mg...@apache.org>.
Calling Session#detach() after RequestCycleListeners#onDetach() and
not using RCL for Session#invalidate() seems to solve the problem.
It seems even before the changes for reverse calling of RCLs there was
this problem, because Session#detach() currently is called before
RCLs#onDetach()
On Mon, May 9, 2011 at 3:14 PM, Martin Grigorov <mg...@apache.org> wrote:
> To make it clear: the problem is that now Session#invalidate()
> prepends the new onDetach() listener and thus is executed before
> commitRequest()
>
> On Mon, May 9, 2011 at 3:04 PM, Martin Grigorov <mg...@apache.org> wrote:
>> Hi,
>>
>> Since recently the RequestCycleListeners are executed in reverse order
>> for #onDetach() and #onException(). I.e. registered first - notified
>> last.
>> I'm facing a problem with Session#invalidate(). This method registers
>> a listener with #onDetach() which actually invalidates the http
>> session and null-ifies the Session#sessionStore.
>> In org.apache.wicket.Application.createRequestCycle(Request, Response)
>> we register a listener which executes
>> org.apache.wicket.page.IPageManager.commitRequest() at the end of each
>> request cycle. This listener is setup such way that it is always
>> executed as last.
>> The problem is:
>> - my app calls Session#invalidate() in a callback method (e.g. onClick())
>> - later when the listeners are executed Session#invalidateNow() and
>> Session#destroy() are called (so the http session and sessionStore are
>> destroyed)
>> - even later the special listener is executed [1] and :
>> -- it re-creates a new http session !
>> -- re-uses the same Wicket Session object. See
>> https://issues.apache.org/jira/browse/WICKET-3690 for a member which
>> leaked. But it will leak even worse if there is user impl of
>> WebSession with its own properties.
>>
>> Am I correct in my investigations ?
>>
>>
>> 1.
>> PersistentPageManager$PersitentRequestAdapter(RequestAdapter).bind() line: 80
>> PersistentPageManager$PersitentRequestAdapter.getSessionEntry(boolean)
>> line: 339
>> PersistentPageManager$PersitentRequestAdapter.storeTouchedPages(List<IManageablePage>)
>> line: 373
>> PersistentPageManager$PersitentRequestAdapter(RequestAdapter).commitRequest()
>> line: 185
>> PersistentPageManager(AbstractPageManager).commitRequest() line: 94
>> PageAccessSynchronizer$1(PageManagerDecorator).commitRequest() line: 68
>> PageAccessSynchronizer$1.commitRequest() line: 203
>> Application$2.onDetach(RequestCycle) line: 1522
>> RequestCycleListenerCollection$3.notify(IRequestCycleListener) line: 100
>> RequestCycleListenerCollection$3.notify(Object) line: 95
>> RequestCycleListenerCollection(ListenerCollection<T>).reversedNotify(Iterator<T>,
>> INotifier<T>) line: 121
>> RequestCycleListenerCollection(ListenerCollection<T>).reversedNotify(INotifier<T>)
>> line: 112
>> RequestCycleListenerCollection.onDetach(RequestCycle) line: 94
>> RequestCycle.onDetach() line: 547
>> RequestCycle.detach() line: 479
>> RequestCycle.processRequestAndDetach() line: 257
>> ....
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: Problem with Session#invalidate()
Posted by Martin Grigorov <mg...@apache.org>.
To make it clear: the problem is that now Session#invalidate()
prepends the new onDetach() listener and thus is executed before
commitRequest()
On Mon, May 9, 2011 at 3:04 PM, Martin Grigorov <mg...@apache.org> wrote:
> Hi,
>
> Since recently the RequestCycleListeners are executed in reverse order
> for #onDetach() and #onException(). I.e. registered first - notified
> last.
> I'm facing a problem with Session#invalidate(). This method registers
> a listener with #onDetach() which actually invalidates the http
> session and null-ifies the Session#sessionStore.
> In org.apache.wicket.Application.createRequestCycle(Request, Response)
> we register a listener which executes
> org.apache.wicket.page.IPageManager.commitRequest() at the end of each
> request cycle. This listener is setup such way that it is always
> executed as last.
> The problem is:
> - my app calls Session#invalidate() in a callback method (e.g. onClick())
> - later when the listeners are executed Session#invalidateNow() and
> Session#destroy() are called (so the http session and sessionStore are
> destroyed)
> - even later the special listener is executed [1] and :
> -- it re-creates a new http session !
> -- re-uses the same Wicket Session object. See
> https://issues.apache.org/jira/browse/WICKET-3690 for a member which
> leaked. But it will leak even worse if there is user impl of
> WebSession with its own properties.
>
> Am I correct in my investigations ?
>
>
> 1.
> PersistentPageManager$PersitentRequestAdapter(RequestAdapter).bind() line: 80
> PersistentPageManager$PersitentRequestAdapter.getSessionEntry(boolean)
> line: 339
> PersistentPageManager$PersitentRequestAdapter.storeTouchedPages(List<IManageablePage>)
> line: 373
> PersistentPageManager$PersitentRequestAdapter(RequestAdapter).commitRequest()
> line: 185
> PersistentPageManager(AbstractPageManager).commitRequest() line: 94
> PageAccessSynchronizer$1(PageManagerDecorator).commitRequest() line: 68
> PageAccessSynchronizer$1.commitRequest() line: 203
> Application$2.onDetach(RequestCycle) line: 1522
> RequestCycleListenerCollection$3.notify(IRequestCycleListener) line: 100
> RequestCycleListenerCollection$3.notify(Object) line: 95
> RequestCycleListenerCollection(ListenerCollection<T>).reversedNotify(Iterator<T>,
> INotifier<T>) line: 121
> RequestCycleListenerCollection(ListenerCollection<T>).reversedNotify(INotifier<T>)
> line: 112
> RequestCycleListenerCollection.onDetach(RequestCycle) line: 94
> RequestCycle.onDetach() line: 547
> RequestCycle.detach() line: 479
> RequestCycle.processRequestAndDetach() line: 257
> ....
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com