r1101345 All the authen/auth tests/apps I know work with this fix.
On Mon, May 9, 2011 at 9:58 PM, Martin Grigorov <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
