|
| Re: Global UICallback and session timeouts [message #695644 is a reply to message #695172] |
Tue, 12 July 2011 08:16   |
Eclipse User |
|
|
|
Originally posted by:
Sabine,
we are right now reworking the UICallback subsystem and hope to resolve
or otherwise find workable solutions for most of its current issues.
I'd like to ask you to keep an eye on these bugs:
* 260117: UICallBack breaks after failed request
https://bugs.eclipse.org/bugs/show_bug.cgi?id=260117
* 344989: Redesign UICallback subsystem
https://bugs.eclipse.org/bugs/show_bug.cgi?id=344989
* 214464: [UICallback] Unable to close equinox if activated
https://bugs.eclipse.org/bugs/show_bug.cgi?id=214464
let us know if your problems are gone, and once they are resolved.
Regards,
Rüdiger
On 11.07.2011 09:52, Sabine Neubauer wrote:
> Hi all,
>
> first of all sorry for a further post to UICallBack and session
> timeouts. I know there are already many posts to this topic but I did
> not find the answers I search for.
>
> In our application (based on RAP 1.4) we need to activate UICallBack
> globally because we do not know in advance when UI updates are needed
> because they are triggered by user interactions.
>
> Therefore, we activate the UICallBack in
> com.ontoprise.rap.test.ApplicationWorkbenchAdvisor.postStartup() and add
> a SessionStoreListener for deactivating it and doing some cleanup.
>
>
> public void postStartup() {
> UICallBack.activate(RWT.getSessionStore().getId());
> RWT.getSessionStore().addSessionStoreListener(new
> SessionStoreListener(){ @Override
> public void beforeDestroy(SessionStoreEvent event) {
> UICallBack.deactivate(RWT.getSessionStore().getId());
> System.out.println(RWT.getSessionStore().getId() + ": before destroy");
> }
> });
> }
>
>
> Our observations are the following:
> 1. Reloading the page
> - SessionStoreListener.beforeDestroy is called
> - same UIThread is used afterwards
> 2. Session timeout page
> - session timeout page appears
> - clicking the link creates a new UIThread
> - SessionStoreListener.beforeDestroy is never called and the former
> UIThread hangs
> 3. Closing browser/browser tab
> - SessionStoreListener.beforeDestroy is never called and the UIThread hangs
>
> This is in parts contradictory to this post
> www.eclipse.org/forums/index.php/m/674486/?srch=session+timeout#msg_674486
> and leads to many hanging UIThreads.
> Is this behavior a bug or is our way to activate/deactivate UICallBack
> the wrong one?
>
> Our current workaround is to maintain all created sessions by a
> singleton with application scope. A background thread validates them
> periodically (dependent on maxInactiveInterval) and invalidates the
> underlying HttpSession if the gap between current time and last accessed
> time is greater than maxInactiveInterval. If a session timeouts
> independently of our workaround it is removed from the list of
> maintained sessions. Is this workaround ok or are there any side effects?
>
> Kind regards,
> Sabine Neubauer
>
> P.S. I have to "destory" the hyperlink because I am not allowed to post
> links.
--
Rüdiger Herrmann
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
|
|
| Re: Global UICallback and session timeouts [message #695869 is a reply to message #695759] |
Tue, 12 July 2011 17:19 |
| Eclipse User |
|
|
|
Originally posted by:
Sabine,
please see my comment below.
- Rüdiger
On 12.07.2011 15:52, Sabine Neubauer wrote:
> Hi Rüdiger,
>
> thanks for your response.
> I now observe all three bugs you have mentioned and will retest the
> problem against CVS HEAD as soon as the redesign is complete.
> * 260117: UICallBack breaks after failed request
> I don't think that in this case a failed request is the cause of the
> problem. I use HttpFox for observing the requests and there are
> currently no failed ones.
Sorry for the confusion, this issue is unrelated to your current
problems. I just mentioned it as we will be working on this.
>
> * 344989: Redesign UICallback subsystem
> This redesign only affects RAP 1.5. Does this mean that there won't be
> any improvements on the RAP 1.4 maintenance branch in this context? Or
> is there a chance to fix the problem described above on the RAP 1.4
> branch? Should I file a bugzilla for this issue with a small snippet?
The redesign itself we won't backport to 1.4. Certain bugs that are
already known (certainly the one below) or that we discover along the
way will be considered for 1.4.
The goal of the redesign is to simplify the structure of the UICallback
subsystem in order to be able to fix bugs easier and make it more robust.
>
> * 214464: [UICallback] Unable to close equinox if activated
> This problem also exists in our application. I commented the bug
> yesterday and described our current workaround for this problem.
>
> What do you think about our workaround? Are there any side-effects if I
> invalidate the session by myself via
> javax.servlet.http.HttpSession.invalidate()?
Your workaround looks OK. Calling invalidate() from application code
should be perfectly OK as it is part of the public servlet API.
However, it is a workaround and not a trivial one as you implement large
parts of what the servlet engines' session manager provides.
I Hope that we can fix this issue soon so that your workaround becomes
obsolete.
>
> Best,
> Sabine
--
Rüdiger Herrmann
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
|
|
Powered by
FUDForum. Page generated in 0.03071 seconds
] 
Search
Help
Register
Login
Home
