Home » Eclipse Projects » Remote Application Platform (RAP) » cleanup after non-normal exit (Refresh or close browser instead of return from createUI())
| cleanup after non-normal exit (Refresh or close browser instead of return from createUI()) [message #132789] |
Wed, 13 May 2009 22:42  |
 Ryan Donnelly
Messages: 35
Registered: July 2009 |
Member |
|
|
Hi,
We have a complicated RAP application, single-sourced SWT/RWT starting
from our original SWT application, running in Tomcat 6.0.18, RAP 1.2 M7,
the basic structure of which I have sketched below.
public int createUI()
{
UICallBack.activate(getClass().getName());
RWT.getSessionStore().addSessionStoreListener(new
SessionStoreListener() {
public void beforeDestroy(SessionStoreEvent event) {
if not already disposed {
...dispose shells, close db connection, etc....
}
UICallBack.deactivate(getClass().getName());
}
});
...open shells, db connection, etc....
...read and dispatch loop...
...dispose shells, close db connection, etc....
RWT.getRequest().getSession().setMaxInactiveInterval(1);
return 0;
}
Running the app and exiting by returning from createUI() works fine.
The problem I am trying to solve is how to clean up after a non-normal
exit, caused by navigating to a new web page, hitting F5 (refresh),
closing the browser, etc.
From reading the newsgroup and bugzilla, I have learned the following:
1) Implement a SessionStoreListener to do your cleanup. It will get
called before the session is destroyed, including:
a) when a new session is created after F5 (refresh) or re-addressing
the application start page
b) when the session is destroyed after a timeout (e.g. after the
browser is closed)
2) Upon normal exit, set the session timeout to 1 second so that the
session is destroyed quickly and will not have to wait for timeout:
RWT.getRequest().getSession().setMaxInactiveInterval(1);
When I exit my application normally, and createUI returns, I have no
problems, but when I exit through the abnormal path (F5, close browser,
session timeout, etc.), I can see a memory leak in Tomcat.
Suspects:
1) Disposing of SWT shells, etc. As far as i can tell I am doing this
correctly, calling the same code in the SessionStoreListener which is
getting called when I exit through the normal path.
2) Disposing of Images. I have seen some discussion in the newsgroup
suggesting that special work may need to be done to dispose of Images.
Again, as far as I can see, I am calling the same cleanup code in the
SessionStoreListener that I call when exiting through the normal path.
As it seems to me that, from my end, I am doing the same cleanup in the
SessionStoreListener as I do in the normal app exit path, I would like
to ask for some clarification as to what is going on the RAP side. Is
there something more I need to call on the RAP side from the
SessionStoreListener, to destroy the current thread, etc? Does the
normal exit path do any cleanup after returning from createUI that it
would not in the case of an abnormal exit through F5 (Refresh) or
session timeout? I don't see anything obvious in the examples in the
RAP source code, such as:
RWTDemo
RWTLifeCycle2_Test$EventProcessingOnSessionRestartEntryPoint
Some relevant postings and bugs:
Disposing:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=247704
https://bugs.eclipse.org/bugs/show_bug.cgi?id=253763
http://dev.eclipse.org/newslists/news.eclipse.technology.rap /msg03996.html
Images:
news://news.eclipse.org:119/497F6B5E.8808.0090.0@kabe-farben .ch
news://news.eclipse.org:119/gl9eoc$uoo$1@build.eclipse.org
news://news.eclipse.org:119/e1ad67dfb09b1ae8721919cda6c56e27 $1@www.eclipse.org
Any ideas are appreciated.
Thanks,
Ryan
|
|
|
| Re: cleanup after non-normal exit (Refresh or close browser instead of return from createUI()) [message #132828 is a reply to message #132789] |
Thu, 14 May 2009 11:31  |
Rüdiger Herrmann
Messages: 581
Registered: July 2009 |
Senior Member |
|
|
Ryan,
your observations and findings are right and your code should just
run fine.
We just recently fixed two bugs ([1] and [2]) that you most likely
run into. The changes are in CVS HEAD and will go into the RC1 build.
Ideally there wouldn't be two paths and session invalidation code
would always be executed under the same conditions. But we aren't
there yet (see [1] and depedant bugs).
Images in RAP differ from their SWT counterparts in that they are
only made of a string to identify them and their width and height.
In addition they don't have session scope but are held in an
application-scoped map. The links related to images you provided
were about custom ways to deal with images. Naturally, you need free
these resources that you allocated.
HTH
Rüdiger
[1] 275332: Possible memory leak after session invalidate
https://bugs.eclipse.org/bugs/show_bug.cgi?id=275332
[2] 262220: Invalid Thread Access
https://bugs.eclipse.org/bugs/show_bug.cgi?id=262220
[3] 219789: Finalize Display#readAndDispatch
https://bugs.eclipse.org/bugs/show_bug.cgi?id=219789
Ryan Donnelly wrote:
> Hi,
> We have a complicated RAP application, single-sourced SWT/RWT
> starting from our original SWT application, running in Tomcat 6.0.18,
> RAP 1.2 M7, the basic structure of which I have sketched below.
>
> public int createUI()
> {
> UICallBack.activate(getClass().getName());
>
> RWT.getSessionStore().addSessionStoreListener(new
> SessionStoreListener() {
> public void beforeDestroy(SessionStoreEvent event) {
>
> if not already disposed {
> ...dispose shells, close db connection, etc....
> }
>
> UICallBack.deactivate(getClass().getName());
> }
> });
>
> ...open shells, db connection, etc....
>
> ...read and dispatch loop...
>
> ...dispose shells, close db connection, etc....
>
> RWT.getRequest().getSession().setMaxInactiveInterval(1);
>
> return 0;
> }
>
>
> Running the app and exiting by returning from createUI() works fine. The
> problem I am trying to solve is how to clean up after a non-normal exit,
> caused by navigating to a new web page, hitting F5 (refresh), closing
> the browser, etc.
>
> From reading the newsgroup and bugzilla, I have learned the following:
>
> 1) Implement a SessionStoreListener to do your cleanup. It will get
> called before the session is destroyed, including:
>
> a) when a new session is created after F5 (refresh) or re-addressing
> the application start page
>
> b) when the session is destroyed after a timeout (e.g. after the
> browser is closed)
>
> 2) Upon normal exit, set the session timeout to 1 second so that the
> session is destroyed quickly and will not have to wait for timeout:
> RWT.getRequest().getSession().setMaxInactiveInterval(1);
>
>
> When I exit my application normally, and createUI returns, I have no
> problems, but when I exit through the abnormal path (F5, close browser,
> session timeout, etc.), I can see a memory leak in Tomcat.
>
> Suspects:
>
> 1) Disposing of SWT shells, etc. As far as i can tell I am doing
> this correctly, calling the same code in the SessionStoreListener which
> is getting called when I exit through the normal path.
>
> 2) Disposing of Images. I have seen some discussion in the
> newsgroup suggesting that special work may need to be done to dispose of
> Images. Again, as far as I can see, I am calling the same cleanup code
> in the SessionStoreListener that I call when exiting through the normal
> path.
>
>
> As it seems to me that, from my end, I am doing the same cleanup in
> the SessionStoreListener as I do in the normal app exit path, I would
> like to ask for some clarification as to what is going on the RAP side.
> Is there something more I need to call on the RAP side from the
> SessionStoreListener, to destroy the current thread, etc? Does the
> normal exit path do any cleanup after returning from createUI that it
> would not in the case of an abnormal exit through F5 (Refresh) or
> session timeout? I don't see anything obvious in the examples in the
> RAP source code, such as:
>
> RWTDemo
> RWTLifeCycle2_Test$EventProcessingOnSessionRestartEntryPoint
>
> Some relevant postings and bugs:
> Disposing:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247704
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=253763
> http://dev.eclipse.org/newslists/news.eclipse.technology.rap /msg03996.html
>
> Images:
>
> news://news.eclipse.org:119/497F6B5E.8808.0090.0@kabe-farben .ch
> news://news.eclipse.org:119/gl9eoc$uoo$1@build.eclipse.org
> news://news.eclipse.org:119/e1ad67dfb09b1ae8721919cda6c56e27 $1@www.eclipse.org
>
>
>
> Any ideas are appreciated.
>
> Thanks,
>
> Ryan
|
|
|
| Re: cleanup after non-normal exit (Refresh or close browser instead of return from createUI()) [message #132898 is a reply to message #132828] |
Thu, 14 May 2009 18:28 |
Ryan Donnelly
Messages: 35
Registered: July 2009 |
Member |
|
|
Rüdiger,
Thanks for the information. Unfortunately, I rebuilt my app with the
latest RAP CVS and still have the problem. Are you expecting to have
this and its blocking issues fixed for the 1.2 Galileo release?
[3] 219789: Finalize Display#readAndDispatch
https://bugs.eclipse.org/bugs/show_bug.cgi?id=219789
I will look into the image resource management. As I say, I think I am
calling the same code in both exit paths, so I don't think that is this
problem in this case, but it could certainly represent a different
memory leak.
Thanks,
Ryan
Rüdiger Herrmann wrote:
> Ryan,
>
> your observations and findings are right and your code should just run
> fine.
> We just recently fixed two bugs ([1] and [2]) that you most likely run
> into. The changes are in CVS HEAD and will go into the RC1 build.
> Ideally there wouldn't be two paths and session invalidation code would
> always be executed under the same conditions. But we aren't there yet
> (see [1] and depedant bugs).
> Images in RAP differ from their SWT counterparts in that they are only
> made of a string to identify them and their width and height.
> In addition they don't have session scope but are held in an
> application-scoped map. The links related to images you provided were
> about custom ways to deal with images. Naturally, you need free these
> resources that you allocated.
>
> HTH
> Rüdiger
>
> [1] 275332: Possible memory leak after session invalidate
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=275332
> [2] 262220: Invalid Thread Access
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=262220
> [3] 219789: Finalize Display#readAndDispatch
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=219789
>
>
>
> Ryan Donnelly wrote:
>> Hi,
>> We have a complicated RAP application, single-sourced SWT/RWT
>> starting from our original SWT application, running in Tomcat 6.0.18,
>> RAP 1.2 M7, the basic structure of which I have sketched below.
>>
>> public int createUI()
>> {
>> UICallBack.activate(getClass().getName());
>>
>> RWT.getSessionStore().addSessionStoreListener(new
>> SessionStoreListener() {
>> public void beforeDestroy(SessionStoreEvent event) {
>> if not already disposed {
>> ...dispose shells, close db connection, etc....
>> }
>>
>> UICallBack.deactivate(getClass().getName()); }
>> });
>>
>> ...open shells, db connection, etc....
>>
>> ...read and dispatch loop...
>>
>> ...dispose shells, close db connection, etc....
>>
>> RWT.getRequest().getSession().setMaxInactiveInterval(1);
>> return 0; }
>>
>>
>> Running the app and exiting by returning from createUI() works fine.
>> The problem I am trying to solve is how to clean up after a non-normal
>> exit, caused by navigating to a new web page, hitting F5 (refresh),
>> closing the browser, etc.
>>
>> From reading the newsgroup and bugzilla, I have learned the following:
>>
>> 1) Implement a SessionStoreListener to do your cleanup. It will get
>> called before the session is destroyed, including:
>>
>> a) when a new session is created after F5 (refresh) or
>> re-addressing the application start page
>>
>> b) when the session is destroyed after a timeout (e.g. after the
>> browser is closed)
>>
>> 2) Upon normal exit, set the session timeout to 1 second so that the
>> session is destroyed quickly and will not have to wait for timeout:
>> RWT.getRequest().getSession().setMaxInactiveInterval(1);
>>
>>
>> When I exit my application normally, and createUI returns, I have no
>> problems, but when I exit through the abnormal path (F5, close
>> browser, session timeout, etc.), I can see a memory leak in Tomcat.
>>
>> Suspects:
>>
>> 1) Disposing of SWT shells, etc. As far as i can tell I am doing
>> this correctly, calling the same code in the SessionStoreListener
>> which is getting called when I exit through the normal path.
>>
>> 2) Disposing of Images. I have seen some discussion in the
>> newsgroup suggesting that special work may need to be done to dispose
>> of Images. Again, as far as I can see, I am calling the same cleanup
>> code in the SessionStoreListener that I call when exiting through the
>> normal path.
>>
>>
>> As it seems to me that, from my end, I am doing the same cleanup
>> in the SessionStoreListener as I do in the normal app exit path, I
>> would like to ask for some clarification as to what is going on the
>> RAP side. Is there something more I need to call on the RAP side from
>> the SessionStoreListener, to destroy the current thread, etc? Does
>> the normal exit path do any cleanup after returning from createUI that
>> it would not in the case of an abnormal exit through F5 (Refresh) or
>> session timeout? I don't see anything obvious in the examples in the
>> RAP source code, such as:
>>
>> RWTDemo
>> RWTLifeCycle2_Test$EventProcessingOnSessionRestartEntryPoint
>>
>> Some relevant postings and bugs:
>> Disposing:
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247704
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=253763
>> http://dev.eclipse.org/newslists/news.eclipse.technology.rap /msg03996.html
>>
>>
>> Images:
>>
>> news://news.eclipse.org:119/497F6B5E.8808.0090.0@kabe-farben .ch
>> news://news.eclipse.org:119/gl9eoc$uoo$1@build.eclipse.org
>> news://news.eclipse.org:119/e1ad67dfb09b1ae8721919cda6c56e27 $1@www.eclipse.org
>>
>>
>>
>> Any ideas are appreciated.
>>
>> Thanks,
>>
>> Ryan
|
|
|
| Re: cleanup after non-normal exit (Refresh or close browser instead of return from createUI()) [message #132954 is a reply to message #132789] |
Fri, 15 May 2009 06:50 |
Stefan 
Messages: 316
Registered: July 2009 |
Senior Member |
|
|
Hi Ryan,
Although this is not your question, I don't think that this line works:
> UICallBack.deactivate(getClass().getName());
getClass() would be sth different than during activation as it is called
from within an anonymous class.
Regards,
Stefan.
> Hi,
> We have a complicated RAP application, single-sourced SWT/RWT
> starting from our original SWT application, running in Tomcat 6.0.18,
> RAP 1.2 M7, the basic structure of which I have sketched below.
>
> public int createUI()
> {
> UICallBack.activate(getClass().getName());
>
> RWT.getSessionStore().addSessionStoreListener(new
> SessionStoreListener() {
> public void beforeDestroy(SessionStoreEvent event) {
>
> if not already disposed {
> ...dispose shells, close db connection, etc....
> }
>
> UICallBack.deactivate(getClass().getName());
> }
> });
>
> ...open shells, db connection, etc....
>
> ...read and dispatch loop...
>
> ...dispose shells, close db connection, etc....
>
> RWT.getRequest().getSession().setMaxInactiveInterval(1);
>
> return 0;
> }
>
|
|
|
| Re: cleanup after non-normal exit (Refresh or close browser instead of return from createUI()) [message #133048 is a reply to message #132898] |
Fri, 15 May 2009 11:26 |
Rüdiger Herrmann
Messages: 581
Registered: July 2009 |
Senior Member |
|
|
Ryan,
we will not be able to resolve the "Finalize
Display#readAndDispatch" issue in 1.2. But note that this bug is
mostly about streamlining the internal session-termination handling.
Nonetheless shouldn't there any memory leaks if you execute the same
code in both paths.
Could you come up with a mini-plug-in or a snippet that causes the
memory leak? Preferably open a bugzilla to attach it.
Cheers,
Rüdiger
Ryan Donnelly wrote:
> Rüdiger,
> Thanks for the information. Unfortunately, I rebuilt my app with
> the latest RAP CVS and still have the problem. Are you expecting to
> have this and its blocking issues fixed for the 1.2 Galileo release?
>
> [3] 219789: Finalize Display#readAndDispatch
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=219789
>
> I will look into the image resource management. As I say, I think I
> am calling the same code in both exit paths, so I don't think that is
> this problem in this case, but it could certainly represent a different
> memory leak.
>
>
> Thanks,
>
> Ryan
>
>
> Rüdiger Herrmann wrote:
>> Ryan,
>>
>> your observations and findings are right and your code should just run
>> fine.
>> We just recently fixed two bugs ([1] and [2]) that you most likely run
>> into. The changes are in CVS HEAD and will go into the RC1 build.
>> Ideally there wouldn't be two paths and session invalidation code
>> would always be executed under the same conditions. But we aren't
>> there yet (see [1] and depedant bugs).
>> Images in RAP differ from their SWT counterparts in that they are only
>> made of a string to identify them and their width and height.
>> In addition they don't have session scope but are held in an
>> application-scoped map. The links related to images you provided were
>> about custom ways to deal with images. Naturally, you need free these
>> resources that you allocated.
>>
>> HTH
>> Rüdiger
>>
>> [1] 275332: Possible memory leak after session invalidate
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=275332
>> [2] 262220: Invalid Thread Access
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=262220
>> [3] 219789: Finalize Display#readAndDispatch
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=219789
>>
>>
>>
>> Ryan Donnelly wrote:
>>> Hi,
>>> We have a complicated RAP application, single-sourced SWT/RWT
>>> starting from our original SWT application, running in Tomcat 6.0.18,
>>> RAP 1.2 M7, the basic structure of which I have sketched below.
>>>
>>> public int createUI()
>>> {
>>> UICallBack.activate(getClass().getName());
>>>
>>> RWT.getSessionStore().addSessionStoreListener(new
>>> SessionStoreListener() {
>>> public void beforeDestroy(SessionStoreEvent event) {
>>> if not already disposed {
>>> ...dispose shells, close db connection, etc....
>>> }
>>>
>>> UICallBack.deactivate(getClass().getName()); }
>>> });
>>>
>>> ...open shells, db connection, etc....
>>>
>>> ...read and dispatch loop...
>>>
>>> ...dispose shells, close db connection, etc....
>>>
>>> RWT.getRequest().getSession().setMaxInactiveInterval(1);
>>> return 0; }
>>>
>>>
>>> Running the app and exiting by returning from createUI() works fine.
>>> The problem I am trying to solve is how to clean up after a
>>> non-normal exit, caused by navigating to a new web page, hitting F5
>>> (refresh), closing the browser, etc.
>>>
>>> From reading the newsgroup and bugzilla, I have learned the following:
>>>
>>> 1) Implement a SessionStoreListener to do your cleanup. It will get
>>> called before the session is destroyed, including:
>>>
>>> a) when a new session is created after F5 (refresh) or
>>> re-addressing the application start page
>>>
>>> b) when the session is destroyed after a timeout (e.g. after the
>>> browser is closed)
>>>
>>> 2) Upon normal exit, set the session timeout to 1 second so that the
>>> session is destroyed quickly and will not have to wait for timeout:
>>> RWT.getRequest().getSession().setMaxInactiveInterval(1);
>>>
>>>
>>> When I exit my application normally, and createUI returns, I have no
>>> problems, but when I exit through the abnormal path (F5, close
>>> browser, session timeout, etc.), I can see a memory leak in Tomcat.
>>>
>>> Suspects:
>>>
>>> 1) Disposing of SWT shells, etc. As far as i can tell I am doing
>>> this correctly, calling the same code in the SessionStoreListener
>>> which is getting called when I exit through the normal path.
>>>
>>> 2) Disposing of Images. I have seen some discussion in the
>>> newsgroup suggesting that special work may need to be done to dispose
>>> of Images. Again, as far as I can see, I am calling the same cleanup
>>> code in the SessionStoreListener that I call when exiting through the
>>> normal path.
>>>
>>>
>>> As it seems to me that, from my end, I am doing the same cleanup
>>> in the SessionStoreListener as I do in the normal app exit path, I
>>> would like to ask for some clarification as to what is going on the
>>> RAP side. Is there something more I need to call on the RAP side
>>> from the SessionStoreListener, to destroy the current thread, etc?
>>> Does the normal exit path do any cleanup after returning from
>>> createUI that it would not in the case of an abnormal exit through F5
>>> (Refresh) or session timeout? I don't see anything obvious in the
>>> examples in the RAP source code, such as:
>>>
>>> RWTDemo
>>> RWTLifeCycle2_Test$EventProcessingOnSessionRestartEntryPoint
>>>
>>> Some relevant postings and bugs:
>>> Disposing:
>>>
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247704
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=253763
>>> http://dev.eclipse.org/newslists/news.eclipse.technology.rap /msg03996.html
>>>
>>>
>>> Images:
>>>
>>> news://news.eclipse.org:119/497F6B5E.8808.0090.0@kabe-farben .ch
>>> news://news.eclipse.org:119/gl9eoc$uoo$1@build.eclipse.org
>>> news://news.eclipse.org:119/e1ad67dfb09b1ae8721919cda6c56e27 $1@www.eclipse.org
>>>
>>>
>>>
>>> Any ideas are appreciated.
>>>
>>> Thanks,
>>>
>>> Ryan
|
|
|
| Re: cleanup after non-normal exit (Refresh or close browser instead of return from createUI()) [message #133061 is a reply to message #132954] |
Fri, 15 May 2009 13:48 |
Ryan Donnelly
Messages: 35
Registered: July 2009 |
Member |
|
|
Stefan,
You're right, that was an oversight. I've fixed it to:
public int createUI()
{
final String httpSessionId = RWT.getSessionStore().getId();
UICallBack.activate(httpSessionId);
...
RWT.getSessionStore().addSessionStoreListener(new
SessionStoreListener() {
public void beforeDestroy(SessionStoreEvent event) {
final String httpSessionId = event.getSessionStore().getId();
UICallBack.deactivate(httpSessionId);
...
}
});
...
return 0;
}
I have retested and this has not fixed the memory leak, but thank you
for catching that.
-Ryan
Stefan Roeck wrote:
> Hi Ryan,
>
> Although this is not your question, I don't think that this line works:
>
> > UICallBack.deactivate(getClass().getName());
>
> getClass() would be sth different than during activation as it is called
> from within an anonymous class.
>
> Regards,
> Stefan.
>
>
>> Hi,
>> We have a complicated RAP application, single-sourced SWT/RWT
>> starting from our original SWT application, running in Tomcat 6.0.18,
>> RAP 1.2 M7, the basic structure of which I have sketched below.
>>
>> public int createUI()
>> {
>> UICallBack.activate(getClass().getName());
>>
>> RWT.getSessionStore().addSessionStoreListener(new
>> SessionStoreListener() {
>> public void beforeDestroy(SessionStoreEvent event) {
>> if not already disposed {
>> ...dispose shells, close db connection, etc....
>> }
>>
>> UICallBack.deactivate(getClass().getName()); }
>> });
>>
>> ...open shells, db connection, etc....
>>
>> ...read and dispatch loop...
>>
>> ...dispose shells, close db connection, etc....
>>
>> RWT.getRequest().getSession().setMaxInactiveInterval(1);
>> return 0; }
>>
|
|
|
| Re: cleanup after non-normal exit (Refresh or close browser instead of return from createUI()) [message #133074 is a reply to message #133048] |
Fri, 15 May 2009 13:50 |
Ryan Donnelly
Messages: 35
Registered: July 2009 |
Member |
|
|
Rüdiger,
Thank you, I will re-examine my code with this in mind and post a bug
or message depending upon my conclusions.
-Ryan
Rüdiger Herrmann wrote:
> Ryan,
>
> we will not be able to resolve the "Finalize Display#readAndDispatch"
> issue in 1.2. But note that this bug is mostly about streamlining the
> internal session-termination handling.
>
> Nonetheless shouldn't there any memory leaks if you execute the same
> code in both paths.
>
> Could you come up with a mini-plug-in or a snippet that causes the
> memory leak? Preferably open a bugzilla to attach it.
>
> Cheers,
> Rüdiger
>
>
>
> Ryan Donnelly wrote:
>> Rüdiger,
>> Thanks for the information. Unfortunately, I rebuilt my app with
>> the latest RAP CVS and still have the problem. Are you expecting to
>> have this and its blocking issues fixed for the 1.2 Galileo release?
>>
>> [3] 219789: Finalize Display#readAndDispatch
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=219789
>>
>> I will look into the image resource management. As I say, I think
>> I am calling the same code in both exit paths, so I don't think that
>> is this problem in this case, but it could certainly represent a
>> different memory leak.
>>
>>
>> Thanks,
>>
>> Ryan
>>
>>
>> Rüdiger Herrmann wrote:
>>> Ryan,
>>>
>>> your observations and findings are right and your code should just
>>> run fine.
>>> We just recently fixed two bugs ([1] and [2]) that you most likely
>>> run into. The changes are in CVS HEAD and will go into the RC1 build.
>>> Ideally there wouldn't be two paths and session invalidation code
>>> would always be executed under the same conditions. But we aren't
>>> there yet (see [1] and depedant bugs).
>>> Images in RAP differ from their SWT counterparts in that they are
>>> only made of a string to identify them and their width and height.
>>> In addition they don't have session scope but are held in an
>>> application-scoped map. The links related to images you provided were
>>> about custom ways to deal with images. Naturally, you need free these
>>> resources that you allocated.
>>>
>>> HTH
>>> Rüdiger
>>>
>>> [1] 275332: Possible memory leak after session invalidate
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=275332
>>> [2] 262220: Invalid Thread Access
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=262220
>>> [3] 219789: Finalize Display#readAndDispatch
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=219789
>>>
>>>
>>>
>>> Ryan Donnelly wrote:
>>>> Hi,
>>>> We have a complicated RAP application, single-sourced SWT/RWT
>>>> starting from our original SWT application, running in Tomcat
>>>> 6.0.18, RAP 1.2 M7, the basic structure of which I have sketched below.
>>>>
>>>> public int createUI()
>>>> {
>>>> UICallBack.activate(getClass().getName());
>>>>
>>>> RWT.getSessionStore().addSessionStoreListener(new
>>>> SessionStoreListener() {
>>>> public void beforeDestroy(SessionStoreEvent event) {
>>>> if not already disposed {
>>>> ...dispose shells, close db connection, etc....
>>>> }
>>>>
>>>>
>>>> UICallBack.deactivate(getClass().getName()); }
>>>> });
>>>>
>>>> ...open shells, db connection, etc....
>>>>
>>>> ...read and dispatch loop...
>>>>
>>>> ...dispose shells, close db connection, etc....
>>>>
>>>> RWT.getRequest().getSession().setMaxInactiveInterval(1);
>>>> return 0; }
>>>>
>>>>
>>>> Running the app and exiting by returning from createUI() works fine.
>>>> The problem I am trying to solve is how to clean up after a
>>>> non-normal exit, caused by navigating to a new web page, hitting F5
>>>> (refresh), closing the browser, etc.
>>>>
>>>> From reading the newsgroup and bugzilla, I have learned the following:
>>>>
>>>> 1) Implement a SessionStoreListener to do your cleanup. It will get
>>>> called before the session is destroyed, including:
>>>>
>>>> a) when a new session is created after F5 (refresh) or
>>>> re-addressing the application start page
>>>>
>>>> b) when the session is destroyed after a timeout (e.g. after the
>>>> browser is closed)
>>>>
>>>> 2) Upon normal exit, set the session timeout to 1 second so that the
>>>> session is destroyed quickly and will not have to wait for timeout:
>>>> RWT.getRequest().getSession().setMaxInactiveInterval(1);
>>>>
>>>>
>>>> When I exit my application normally, and createUI returns, I have no
>>>> problems, but when I exit through the abnormal path (F5, close
>>>> browser, session timeout, etc.), I can see a memory leak in Tomcat.
>>>>
>>>> Suspects:
>>>>
>>>> 1) Disposing of SWT shells, etc. As far as i can tell I am
>>>> doing this correctly, calling the same code in the
>>>> SessionStoreListener which is getting called when I exit through the
>>>> normal path.
>>>>
>>>> 2) Disposing of Images. I have seen some discussion in the
>>>> newsgroup suggesting that special work may need to be done to
>>>> dispose of Images. Again, as far as I can see, I am calling the same
>>>> cleanup code in the SessionStoreListener that I call when exiting
>>>> through the normal path.
>>>>
>>>>
>>>> As it seems to me that, from my end, I am doing the same cleanup
>>>> in the SessionStoreListener as I do in the normal app exit path, I
>>>> would like to ask for some clarification as to what is going on the
>>>> RAP side. Is there something more I need to call on the RAP side
>>>> from the SessionStoreListener, to destroy the current thread, etc?
>>>> Does the normal exit path do any cleanup after returning from
>>>> createUI that it would not in the case of an abnormal exit through
>>>> F5 (Refresh) or session timeout? I don't see anything obvious in
>>>> the examples in the RAP source code, such as:
>>>>
>>>> RWTDemo
>>>> RWTLifeCycle2_Test$EventProcessingOnSessionRestartEntryPoint
>>>>
>>>> Some relevant postings and bugs:
>>>> Disposing:
>>>>
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247704
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=253763
>>>> http://dev.eclipse.org/newslists/news.eclipse.technology.rap /msg03996.html
>>>>
>>>>
>>>> Images:
>>>>
>>>> news://news.eclipse.org:119/497F6B5E.8808.0090.0@kabe-farben .ch
>>>> news://news.eclipse.org:119/gl9eoc$uoo$1@build.eclipse.org
>>>> news://news.eclipse.org:119/e1ad67dfb09b1ae8721919cda6c56e27 $1@www.eclipse.org
>>>>
>>>>
>>>>
>>>> Any ideas are appreciated.
>>>>
>>>> Thanks,
>>>>
>>>> Ryan
|
|
|
| Re: cleanup after non-normal exit (Refresh or close browser instead of return from createUI()) [message #133111 is a reply to message #133074] |
Fri, 15 May 2009 20:27 |
Ryan Donnelly
Messages: 35
Registered: July 2009 |
Member |
|
|
Rüdiger,
I am noticing an equinox error, showing up in Tomcat's
localhost.XXX.log, same as in the following resolved bug:
#216094 Frequently java.lang.IllegalStateException: The session store is
about to be unbound
https://bugs.eclipse.org/bugs/show_bug.cgi?id=216094
When exiting through the normal path (createUI returns), when my 1s
timeout expires and the SessionStoreListener is entered:
May 15, 2009 5:02:14 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet equinoxbridgeservlet threw exception
java.lang.IllegalStateException: The session store is about to be unbound.
at
org.eclipse.rwt.internal.service.SessionStoreImpl.checkAbout Unbound(SessionStoreImpl.java:251)
at
org.eclipse.rwt.internal.service.SessionStoreImpl.removeSess ionStoreListener(SessionStoreImpl.java:125)
at
org.eclipse.rwt.internal.lifecycle.UICallBackManager.blockCa llBackRequest(UICallBackManager.java:214)
at
org.eclipse.rwt.internal.lifecycle.UICallBackServiceHandler. service(UICallBackServiceHandler.java:418)
at
org.eclipse.rwt.internal.service.ServiceManager$HandlerDispa tcher.service(ServiceManager.java:99)
at org.eclipse.rwt.internal.engine.RWTDelegate.doPost(RWTDelega te.java:63)
at
org.eclipse.rap.ui.internal.servlet.RequestHandler.service(R equestHandler.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.eclipse.equinox.http.servlet.internal.ServletRegistratio n.handleRequest(ServletRegistration.java:90)
at
org.eclipse.equinox.http.servlet.internal.ProxyServlet.proce ssAlias(ProxyServlet.java:111)
at
org.eclipse.equinox.http.servlet.internal.ProxyServlet.servi ce(ProxyServlet.java:59)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.eclipse.equinox.servletbridge.BridgeServlet.service(Brid geServlet.java:120)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFi lter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(App licationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(Standar dWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(Standar dContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHo stValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorRepo rtValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(Standard EngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAd apter.java:286)
at
org.apache.coyote.http11.Http11AprProcessor.process(Http11Ap rProcessor.java:857)
at
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionH andler.process(Http11AprProtocol.java:565)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoin t.java:1509)
at java.lang.Thread.run(Unknown Source)
and, when exiting through the abnormal path, in this case F5 (so the
session is re-opened), I assume also when the SessionStoreListener is
entered, I get either the above error or the similar:
May 15, 2009 5:14:55 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet equinoxbridgeservlet threw exception
java.lang.IllegalStateException: The session store has been unbound.
at
org.eclipse.rwt.internal.service.SessionStoreImpl.checkBound (SessionStoreImpl.java:244)
at
org.eclipse.rwt.internal.service.SessionStoreImpl.removeSess ionStoreListener(SessionStoreImpl.java:126)
at
org.eclipse.rwt.internal.lifecycle.UICallBackManager.blockCa llBackRequest(UICallBackManager.java:214)
at
org.eclipse.rwt.internal.lifecycle.UICallBackServiceHandler. service(UICallBackServiceHandler.java:418)
at
org.eclipse.rwt.internal.service.ServiceManager$HandlerDispa tcher.service(ServiceManager.java:99)
at org.eclipse.rwt.internal.engine.RWTDelegate.doPost(RWTDelega te.java:63)
at
org.eclipse.rap.ui.internal.servlet.RequestHandler.service(R equestHandler.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.eclipse.equinox.http.servlet.internal.ServletRegistratio n.handleRequest(ServletRegistration.java:90)
at
org.eclipse.equinox.http.servlet.internal.ProxyServlet.proce ssAlias(ProxyServlet.java:111)
at
org.eclipse.equinox.http.servlet.internal.ProxyServlet.servi ce(ProxyServlet.java:59)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.eclipse.equinox.servletbridge.BridgeServlet.service(Brid geServlet.java:120)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFi lter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(App licationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(Standar dWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(Standar dContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHo stValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorRepo rtValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(Standard EngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAd apter.java:286)
at
org.apache.coyote.http11.Http11AprProcessor.process(Http11Ap rProcessor.java:857)
at
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionH andler.process(Http11AprProtocol.java:565)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoin t.java:1509)
at java.lang.Thread.run(Unknown Source)
Does this reveal a problem?
Thanks,
Ryan
Ryan Donnelly wrote:
> Rüdiger,
> Thank you, I will re-examine my code with this in mind and post a
> bug or message depending upon my conclusions.
>
> -Ryan
>
>
> Rüdiger Herrmann wrote:
>> Ryan,
>>
>> we will not be able to resolve the "Finalize Display#readAndDispatch"
>> issue in 1.2. But note that this bug is mostly about streamlining the
>> internal session-termination handling.
>>
>> Nonetheless shouldn't there any memory leaks if you execute the same
>> code in both paths.
>>
>> Could you come up with a mini-plug-in or a snippet that causes the
>> memory leak? Preferably open a bugzilla to attach it.
>>
>> Cheers,
>> Rüdiger
>>
>>
>>
>> Ryan Donnelly wrote:
>>> Rüdiger,
>>> Thanks for the information. Unfortunately, I rebuilt my app with
>>> the latest RAP CVS and still have the problem. Are you expecting to
>>> have this and its blocking issues fixed for the 1.2 Galileo release?
>>>
>>> [3] 219789: Finalize Display#readAndDispatch
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=219789
>>>
>>> I will look into the image resource management. As I say, I
>>> think I am calling the same code in both exit paths, so I don't think
>>> that is this problem in this case, but it could certainly represent a
>>> different memory leak.
>>>
>>>
>>> Thanks,
>>>
>>> Ryan
>>>
>>>
>>> Rüdiger Herrmann wrote:
>>>> Ryan,
>>>>
>>>> your observations and findings are right and your code should just
>>>> run fine.
>>>> We just recently fixed two bugs ([1] and [2]) that you most likely
>>>> run into. The changes are in CVS HEAD and will go into the RC1 build.
>>>> Ideally there wouldn't be two paths and session invalidation code
>>>> would always be executed under the same conditions. But we aren't
>>>> there yet (see [1] and depedant bugs).
>>>> Images in RAP differ from their SWT counterparts in that they are
>>>> only made of a string to identify them and their width and height.
>>>> In addition they don't have session scope but are held in an
>>>> application-scoped map. The links related to images you provided
>>>> were about custom ways to deal with images. Naturally, you need free
>>>> these resources that you allocated.
>>>>
>>>> HTH
>>>> Rüdiger
>>>>
>>>> [1] 275332: Possible memory leak after session invalidate
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=275332
>>>> [2] 262220: Invalid Thread Access
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=262220
>>>> [3] 219789: Finalize Display#readAndDispatch
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=219789
>>>>
>>>>
>>>>
>>>> Ryan Donnelly wrote:
>>>>> Hi,
>>>>> We have a complicated RAP application, single-sourced SWT/RWT
>>>>> starting from our original SWT application, running in Tomcat
>>>>> 6.0.18, RAP 1.2 M7, the basic structure of which I have sketched
>>>>> below.
>>>>>
>>>>> public int createUI()
>>>>> {
>>>>> UICallBack.activate(getClass().getName());
>>>>>
>>>>> RWT.getSessionStore().addSessionStoreListener(new
>>>>> SessionStoreListener() {
>>>>> public void beforeDestroy(SessionStoreEvent event) {
>>>>> if not already disposed {
>>>>> ...dispose shells, close db connection, etc....
>>>>> }
>>>>>
>>>>>
>>>>> UICallBack.deactivate(getClass().getName()); }
>>>>> });
>>>>>
>>>>> ...open shells, db connection, etc....
>>>>>
>>>>> ...read and dispatch loop...
>>>>>
>>>>> ...dispose shells, close db connection, etc....
>>>>>
>>>>> RWT.getRequest().getSession().setMaxInactiveInterval(1);
>>>>> return 0; }
>>>>>
>>>>>
>>>>> Running the app and exiting by returning from createUI() works
>>>>> fine. The problem I am trying to solve is how to clean up after a
>>>>> non-normal exit, caused by navigating to a new web page, hitting F5
>>>>> (refresh), closing the browser, etc.
>>>>>
>>>>> From reading the newsgroup and bugzilla, I have learned the
>>>>> following:
>>>>>
>>>>> 1) Implement a SessionStoreListener to do your cleanup. It will
>>>>> get called before the session is destroyed, including:
>>>>>
>>>>> a) when a new session is created after F5 (refresh) or
>>>>> re-addressing the application start page
>>>>>
>>>>> b) when the session is destroyed after a timeout (e.g. after
>>>>> the browser is closed)
>>>>>
>>>>> 2) Upon normal exit, set the session timeout to 1 second so that
>>>>> the session is destroyed quickly and will not have to wait for
>>>>> timeout:
>>>>> RWT.getRequest().getSession().setMaxInactiveInterval(1);
>>>>>
>>>>>
>>>>> When I exit my application normally, and createUI returns, I have
>>>>> no problems, but when I exit through the abnormal path (F5, close
>>>>> browser, session timeout, etc.), I can see a memory leak in Tomcat.
>>>>>
>>>>> Suspects:
>>>>>
>>>>> 1) Disposing of SWT shells, etc. As far as i can tell I am
>>>>> doing this correctly, calling the same code in the
>>>>> SessionStoreListener which is getting called when I exit through
>>>>> the normal path.
>>>>>
>>>>> 2) Disposing of Images. I have seen some discussion in the
>>>>> newsgroup suggesting that special work may need to be done to
>>>>> dispose of Images. Again, as far as I can see, I am calling the
>>>>> same cleanup code in the SessionStoreListener that I call when
>>>>> exiting through the normal path.
>>>>>
>>>>>
>>>>> As it seems to me that, from my end, I am doing the same
>>>>> cleanup in the SessionStoreListener as I do in the normal app exit
>>>>> path, I would like to ask for some clarification as to what is
>>>>> going on the RAP side. Is there something more I need to call on
>>>>> the RAP side from the SessionStoreListener, to destroy the current
>>>>> thread, etc? Does the normal exit path do any cleanup after
>>>>> returning from createUI that it would not in the case of an
>>>>> abnormal exit through F5 (Refresh) or session timeout? I don't see
>>>>> anything obvious in the examples in the RAP source code, such as:
>>>>>
>>>>> RWTDemo
>>>>> RWTLifeCycle2_Test$EventProcessingOnSessionRestartEntryPoint
>>>>>
>>>>> Some relevant postings and bugs:
>>>>> Disposing:
>>>>>
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247704
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=253763
>>>>> http://dev.eclipse.org/newslists/news.eclipse.technology.rap /msg03996.html
>>>>>
>>>>>
>>>>> Images:
>>>>>
>>>>> news://news.eclipse.org:119/497F6B5E.8808.0090.0@kabe-farben .ch
>>>>> news://news.eclipse.org:119/gl9eoc$uoo$1@build.eclipse.org
>>>>> news://news.eclipse.org:119/e1ad67dfb09b1ae8721919cda6c56e27 $1@www.eclipse.org
>>>>>
>>>>>
>>>>>
>>>>> Any ideas are appreciated.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ryan
|
|
|
| Re: cleanup after non-normal exit (Refresh or close browser instead of return from createUI()) [message #133219 is a reply to message #133111] |
Mon, 18 May 2009 11:30 |
Rüdiger Herrmann
Messages: 581
Registered: July 2009 |
Senior Member |
|
|
Ryan,
these exceptions shouldn't happen and likely prevent proper clean
up. Would you mind filing a bugzilla? I think the one you mentioned
dates back to "pre-readAndDispatch" times - a different code base
and thus presumably a different error source.
Cheers,
Rüdiger
Ryan Donnelly wrote:
> Rüdiger,
> I am noticing an equinox error, showing up in Tomcat's
> localhost.XXX.log, same as in the following resolved bug:
>
> #216094 Frequently java.lang.IllegalStateException: The session store is
> about to be unbound
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=216094
>
>
> When exiting through the normal path (createUI returns), when my 1s
> timeout expires and the SessionStoreListener is entered:
>
>
> May 15, 2009 5:02:14 PM org.apache.catalina.core.StandardWrapperValve
> invoke
> SEVERE: Servlet.service() for servlet equinoxbridgeservlet threw exception
> java.lang.IllegalStateException: The session store is about to be unbound.
> at
> org.eclipse.rwt.internal.service.SessionStoreImpl.checkAbout Unbound(SessionStoreImpl.java:251)
>
> at
> org.eclipse.rwt.internal.service.SessionStoreImpl.removeSess ionStoreListener(SessionStoreImpl.java:125)
>
> at
> org.eclipse.rwt.internal.lifecycle.UICallBackManager.blockCa llBackRequest(UICallBackManager.java:214)
>
> at
> org.eclipse.rwt.internal.lifecycle.UICallBackServiceHandler. service(UICallBackServiceHandler.java:418)
>
> at
> org.eclipse.rwt.internal.service.ServiceManager$HandlerDispa tcher.service(ServiceManager.java:99)
>
> at
> org.eclipse.rwt.internal.engine.RWTDelegate.doPost(RWTDelega te.java:63)
> at
> org.eclipse.rap.ui.internal.servlet.RequestHandler.service(R equestHandler.java:51)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
> org.eclipse.equinox.http.servlet.internal.ServletRegistratio n.handleRequest(ServletRegistration.java:90)
>
> at
> org.eclipse.equinox.http.servlet.internal.ProxyServlet.proce ssAlias(ProxyServlet.java:111)
>
> at
> org.eclipse.equinox.http.servlet.internal.ProxyServlet.servi ce(ProxyServlet.java:59)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
> org.eclipse.equinox.servletbridge.BridgeServlet.service(Brid geServlet.java:120)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFi lter(ApplicationFilterChain.java:290)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(App licationFilterChain.java:206)
>
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(Standar dWrapperValve.java:233)
>
> at
> org.apache.catalina.core.StandardContextValve.invoke(Standar dContextValve.java:191)
>
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHo stValve.java:128)
>
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorRepo rtValve.java:102)
>
> at
> org.apache.catalina.core.StandardEngineValve.invoke(Standard EngineValve.java:109)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAd apter.java:286)
> at
> org.apache.coyote.http11.Http11AprProcessor.process(Http11Ap rProcessor.java:857)
>
> at
> org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionH andler.process(Http11AprProtocol.java:565)
>
> at
> org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoin t.java:1509)
> at java.lang.Thread.run(Unknown Source)
>
>
>
> and, when exiting through the abnormal path, in this case F5 (so the
> session is re-opened), I assume also when the SessionStoreListener is
> entered, I get either the above error or the similar:
>
>
> May 15, 2009 5:14:55 PM org.apache.catalina.core.StandardWrapperValve
> invoke
> SEVERE: Servlet.service() for servlet equinoxbridgeservlet threw exception
> java.lang.IllegalStateException: The session store has been unbound.
> at
> org.eclipse.rwt.internal.service.SessionStoreImpl.checkBound (SessionStoreImpl.java:244)
>
> at
> org.eclipse.rwt.internal.service.SessionStoreImpl.removeSess ionStoreListener(SessionStoreImpl.java:126)
>
> at
> org.eclipse.rwt.internal.lifecycle.UICallBackManager.blockCa llBackRequest(UICallBackManager.java:214)
>
> at
> org.eclipse.rwt.internal.lifecycle.UICallBackServiceHandler. service(UICallBackServiceHandler.java:418)
>
> at
> org.eclipse.rwt.internal.service.ServiceManager$HandlerDispa tcher.service(ServiceManager.java:99)
>
> at
> org.eclipse.rwt.internal.engine.RWTDelegate.doPost(RWTDelega te.java:63)
> at
> org.eclipse.rap.ui.internal.servlet.RequestHandler.service(R equestHandler.java:51)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
> org.eclipse.equinox.http.servlet.internal.ServletRegistratio n.handleRequest(ServletRegistration.java:90)
>
> at
> org.eclipse.equinox.http.servlet.internal.ProxyServlet.proce ssAlias(ProxyServlet.java:111)
>
> at
> org.eclipse.equinox.http.servlet.internal.ProxyServlet.servi ce(ProxyServlet.java:59)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
> org.eclipse.equinox.servletbridge.BridgeServlet.service(Brid geServlet.java:120)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFi lter(ApplicationFilterChain.java:290)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(App licationFilterChain.java:206)
>
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(Standar dWrapperValve.java:233)
>
> at
> org.apache.catalina.core.StandardContextValve.invoke(Standar dContextValve.java:191)
>
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHo stValve.java:128)
>
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorRepo rtValve.java:102)
>
> at
> org.apache.catalina.core.StandardEngineValve.invoke(Standard EngineValve.java:109)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAd apter.java:286)
> at
> org.apache.coyote.http11.Http11AprProcessor.process(Http11Ap rProcessor.java:857)
>
> at
> org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionH andler.process(Http11AprProtocol.java:565)
>
> at
> org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoin t.java:1509)
> at java.lang.Thread.run(Unknown Source)
>
>
>
> Does this reveal a problem?
>
>
> Thanks,
>
> Ryan
>
>
>
> Ryan Donnelly wrote:
>> Rüdiger,
>> Thank you, I will re-examine my code with this in mind and post a
>> bug or message depending upon my conclusions.
>>
>> -Ryan
>>
>>
>> Rüdiger Herrmann wrote:
>>> Ryan,
>>>
>>> we will not be able to resolve the "Finalize Display#readAndDispatch"
>>> issue in 1.2. But note that this bug is mostly about streamlining the
>>> internal session-termination handling.
>>>
>>> Nonetheless shouldn't there any memory leaks if you execute the same
>>> code in both paths.
>>>
>>> Could you come up with a mini-plug-in or a snippet that causes the
>>> memory leak? Preferably open a bugzilla to attach it.
>>>
>>> Cheers,
>>> Rüdiger
>>>
>>>
>>>
>>> Ryan Donnelly wrote:
>>>> Rüdiger,
>>>> Thanks for the information. Unfortunately, I rebuilt my app
>>>> with the latest RAP CVS and still have the problem. Are you
>>>> expecting to have this and its blocking issues fixed for the 1.2
>>>> Galileo release?
>>>>
>>>> [3] 219789: Finalize Display#readAndDispatch
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=219789
>>>>
>>>> I will look into the image resource management. As I say, I
>>>> think I am calling the same code in both exit paths, so I don't
>>>> think that is this problem in this case, but it could certainly
>>>> represent a different memory leak.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Ryan
>>>>
>>>>
>>>> Rüdiger Herrmann wrote:
>>>>> Ryan,
>>>>>
>>>>> your observations and findings are right and your code should just
>>>>> run fine.
>>>>> We just recently fixed two bugs ([1] and [2]) that you most likely
>>>>> run into. The changes are in CVS HEAD and will go into the RC1 build.
>>>>> Ideally there wouldn't be two paths and session invalidation code
>>>>> would always be executed under the same conditions. But we aren't
>>>>> there yet (see [1] and depedant bugs).
>>>>> Images in RAP differ from their SWT counterparts in that they are
>>>>> only made of a string to identify them and their width and height.
>>>>> In addition they don't have session scope but are held in an
>>>>> application-scoped map. The links related to images you provided
>>>>> were about custom ways to deal with images. Naturally, you need
>>>>> free these resources that you allocated.
>>>>>
>>>>> HTH
>>>>> Rüdiger
>>>>>
>>>>> [1] 275332: Possible memory leak after session invalidate
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=275332
>>>>> [2] 262220: Invalid Thread Access
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=262220
>>>>> [3] 219789: Finalize Display#readAndDispatch
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=219789
>>>>>
>>>>>
>>>>>
>>>>> Ryan Donnelly wrote:
>>>>>> Hi,
>>>>>> We have a complicated RAP application, single-sourced SWT/RWT
>>>>>> starting from our original SWT application, running in Tomcat
>>>>>> 6.0.18, RAP 1.2 M7, the basic structure of which I have sketched
>>>>>> below.
>>>>>>
>>>>>> public int createUI()
>>>>>> {
>>>>>> UICallBack.activate(getClass().getName());
>>>>>>
>>>>>> RWT.getSessionStore().addSessionStoreListener(new
>>>>>> SessionStoreListener() {
>>>>>> public void beforeDestroy(SessionStoreEvent event) {
>>>>>> if not already disposed {
>>>>>> ...dispose shells, close db connection, etc....
>>>>>> }
>>>>>>
>>>>>>
>>>>>> UICallBack.deactivate(getClass().getName()); }
>>>>>> });
>>>>>>
>>>>>> ...open shells, db connection, etc....
>>>>>>
>>>>>> ...read and dispatch loop...
>>>>>>
>>>>>> ...dispose shells, close db connection, etc....
>>>>>>
>>>>>> RWT.getRequest().getSession().setMaxInactiveInterval(1);
>>>>>> return 0; }
>>>>>>
>>>>>>
>>>>>> Running the app and exiting by returning from createUI() works
>>>>>> fine. The problem I am trying to solve is how to clean up after a
>>>>>> non-normal exit, caused by navigating to a new web page, hitting
>>>>>> F5 (refresh), closing the browser, etc.
>>>>>>
>>>>>> From reading the newsgroup and bugzilla, I have learned the
>>>>>> following:
>>>>>>
>>>>>> 1) Implement a SessionStoreListener to do your cleanup. It will
>>>>>> get called before the session is destroyed, including:
>>>>>>
>>>>>> a) when a new session is created after F5 (refresh) or
>>>>>> re-addressing the application start page
>>>>>>
>>>>>> b) when the session is destroyed after a timeout (e.g. after
>>>>>> the browser is closed)
>>>>>>
>>>>>> 2) Upon normal exit, set the session timeout to 1 second so that
>>>>>> the session is destroyed quickly and will not have to wait for
>>>>>> timeout:
>>>>>> RWT.getRequest().getSession().setMaxInactiveInterval(1);
>>>>>>
>>>>>>
>>>>>> When I exit my application normally, and createUI returns, I have
>>>>>> no problems, but when I exit through the abnormal path (F5, close
>>>>>> browser, session timeout, etc.), I can see a memory leak in Tomcat.
>>>>>>
>>>>>> Suspects:
>>>>>>
>>>>>> 1) Disposing of SWT shells, etc. As far as i can tell I am
>>>>>> doing this correctly, calling the same code in the
>>>>>> SessionStoreListener which is getting called when I exit through
>>>>>> the normal path.
>>>>>>
>>>>>> 2) Disposing of Images. I have seen some discussion in the
>>>>>> newsgroup suggesting that special work may need to be done to
>>>>>> dispose of Images. Again, as far as I can see, I am calling the
>>>>>> same cleanup code in the SessionStoreListener that I call when
>>>>>> exiting through the normal path.
>>>>>>
>>>>>>
>>>>>> As it seems to me that, from my end, I am doing the same
>>>>>> cleanup in the SessionStoreListener as I do in the normal app exit
>>>>>> path, I would like to ask for some clarification as to what is
>>>>>> going on the RAP side. Is there something more I need to call on
>>>>>> the RAP side from the SessionStoreListener, to destroy the current
>>>>>> thread, etc? Does the normal exit path do any cleanup after
>>>>>> returning from createUI that it would not in the case of an
>>>>>> abnormal exit through F5 (Refresh) or session timeout? I don't
>>>>>> see anything obvious in the examples in the RAP source code, such as:
>>>>>>
>>>>>> RWTDemo
>>>>>> RWTLifeCycle2_Test$EventProcessingOnSessionRestartEntryPoint
>>>>>>
>>>>>> Some relevant postings and bugs:
>>>>>> Disposing:
>>>>>>
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247704
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=253763
>>>>>> http://dev.eclipse.org/newslists/news.eclipse.technology.rap /msg03996.html
>>>>>>
>>>>>>
>>>>>> Images:
>>>>>>
>>>>>> news://news.eclipse.org:119/497F6B5E.8808.0090.0@kabe-farben .ch
>>>>>> news://news.eclipse.org:119/gl9eoc$uoo$1@build.eclipse.org
>>>>>> news://news.eclipse.org:119/e1ad67dfb09b1ae8721919cda6c56e27 $1@www.eclipse.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> Any ideas are appreciated.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Ryan
|
|
|
| Re: cleanup after non-normal exit (Refresh or close browser instead of return from createUI()) [message #133561 is a reply to message #133219] |
Tue, 19 May 2009 15:38 |
Ryan Donnelly
Messages: 35
Registered: July 2009 |
Member |
|
|
Filed as:
#276930 Exception when SessionStoreListener is called:
java.lang.IllegalStateException: The session store is about to be unbound
https://bugs.eclipse.org/bugs/show_bug.cgi?id=276930.
Rüdiger Herrmann wrote:
> Ryan,
>
> these exceptions shouldn't happen and likely prevent proper clean up.
> Would you mind filing a bugzilla? I think the one you mentioned dates
> back to "pre-readAndDispatch" times - a different code base and thus
> presumably a different error source.
>
> Cheers,
> Rüdiger
>
> Ryan Donnelly wrote:
>> Rüdiger,
>> I am noticing an equinox error, showing up in Tomcat's
>> localhost.XXX.log, same as in the following resolved bug:
>>
>> #216094 Frequently java.lang.IllegalStateException: The session store
>> is about to be unbound
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=216094
>>
>>
>> When exiting through the normal path (createUI returns), when my
>> 1s timeout expires and the SessionStoreListener is entered:
>>
>>
>> May 15, 2009 5:02:14 PM org.apache.catalina.core.StandardWrapperValve
>> invoke
>> SEVERE: Servlet.service() for servlet equinoxbridgeservlet threw
>> exception
>> java.lang.IllegalStateException: The session store is about to be
>> unbound.
>> at
>> org.eclipse.rwt.internal.service.SessionStoreImpl.checkAbout Unbound(SessionStoreImpl.java:251)
>>
>> at
>> org.eclipse.rwt.internal.service.SessionStoreImpl.removeSess ionStoreListener(SessionStoreImpl.java:125)
>>
>> at
>> org.eclipse.rwt.internal.lifecycle.UICallBackManager.blockCa llBackRequest(UICallBackManager.java:214)
>>
>> at
>> org.eclipse.rwt.internal.lifecycle.UICallBackServiceHandler. service(UICallBackServiceHandler.java:418)
>>
>> at
>> org.eclipse.rwt.internal.service.ServiceManager$HandlerDispa tcher.service(ServiceManager.java:99)
>>
>> at
>> org.eclipse.rwt.internal.engine.RWTDelegate.doPost(RWTDelega te.java:63)
>> at
>> org.eclipse.rap.ui.internal.servlet.RequestHandler.service(R equestHandler.java:51)
>>
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>> at
>> org.eclipse.equinox.http.servlet.internal.ServletRegistratio n.handleRequest(ServletRegistration.java:90)
>>
>> at
>> org.eclipse.equinox.http.servlet.internal.ProxyServlet.proce ssAlias(ProxyServlet.java:111)
>>
>> at
>> org.eclipse.equinox.http.servlet.internal.ProxyServlet.servi ce(ProxyServlet.java:59)
>>
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>> at
>> org.eclipse.equinox.servletbridge.BridgeServlet.service(Brid geServlet.java:120)
>>
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFi lter(ApplicationFilterChain.java:290)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(App licationFilterChain.java:206)
>>
>> at
>> org.apache.catalina.core.StandardWrapperValve.invoke(Standar dWrapperValve.java:233)
>>
>> at
>> org.apache.catalina.core.StandardContextValve.invoke(Standar dContextValve.java:191)
>>
>> at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHo stValve.java:128)
>>
>> at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorRepo rtValve.java:102)
>>
>> at
>> org.apache.catalina.core.StandardEngineValve.invoke(Standard EngineValve.java:109)
>>
>> at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAd apter.java:286)
>>
>> at
>> org.apache.coyote.http11.Http11AprProcessor.process(Http11Ap rProcessor.java:857)
>>
>> at
>> org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionH andler.process(Http11AprProtocol.java:565)
>>
>> at
>> org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoin t.java:1509)
>> at java.lang.Thread.run(Unknown Source)
>>
>>
>>
>> and, when exiting through the abnormal path, in this case F5 (so the
>> session is re-opened), I assume also when the SessionStoreListener is
>> entered, I get either the above error or the similar:
>>
>>
>> May 15, 2009 5:14:55 PM org.apache.catalina.core.StandardWrapperValve
>> invoke
>> SEVERE: Servlet.service() for servlet equinoxbridgeservlet threw
>> exception
>> java.lang.IllegalStateException: The session store has been unbound.
>> at
>> org.eclipse.rwt.internal.service.SessionStoreImpl.checkBound (SessionStoreImpl.java:244)
>>
>> at
>> org.eclipse.rwt.internal.service.SessionStoreImpl.removeSess ionStoreListener(SessionStoreImpl.java:126)
>>
>> at
>> org.eclipse.rwt.internal.lifecycle.UICallBackManager.blockCa llBackRequest(UICallBackManager.java:214)
>>
>> at
>> org.eclipse.rwt.internal.lifecycle.UICallBackServiceHandler. service(UICallBackServiceHandler.java:418)
>>
>> at
>> org.eclipse.rwt.internal.service.ServiceManager$HandlerDispa tcher.service(ServiceManager.java:99)
>>
>> at
>> org.eclipse.rwt.internal.engine.RWTDelegate.doPost(RWTDelega te.java:63)
>> at
>> org.eclipse.rap.ui.internal.servlet.RequestHandler.service(R equestHandler.java:51)
>>
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>> at
>> org.eclipse.equinox.http.servlet.internal.ServletRegistratio n.handleRequest(ServletRegistration.java:90)
>>
>> at
>> org.eclipse.equinox.http.servlet.internal.ProxyServlet.proce ssAlias(ProxyServlet.java:111)
>>
>> at
>> org.eclipse.equinox.http.servlet.internal.ProxyServlet.servi ce(ProxyServlet.java:59)
>>
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>> at
>> org.eclipse.equinox.servletbridge.BridgeServlet.service(Brid geServlet.java:120)
>>
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFi lter(ApplicationFilterChain.java:290)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(App licationFilterChain.java:206)
>>
>> at
>> org.apache.catalina.core.StandardWrapperValve.invoke(Standar dWrapperValve.java:233)
>>
>> at
>> org.apache.catalina.core.StandardContextValve.invoke(Standar dContextValve.java:191)
>>
>> at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHo stValve.java:128)
>>
>> at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorRepo rtValve.java:102)
>>
>> at
>> org.apache.catalina.core.StandardEngineValve.invoke(Standard EngineValve.java:109)
>>
>> at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAd apter.java:286)
>>
>> at
>> org.apache.coyote.http11.Http11AprProcessor.process(Http11Ap rProcessor.java:857)
>>
>> at
>> org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionH andler.process(Http11AprProtocol.java:565)
>>
>> at
>> org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoin t.java:1509)
>> at java.lang.Thread.run(Unknown Source)
>>
>>
>>
>> Does this reveal a problem?
>>
>>
>> Thanks,
>>
>> Ryan
>>
>>
>>
>> Ryan Donnelly wrote:
>>> Rüdiger,
>>> Thank you, I will re-examine my code with this in mind and post a
>>> bug or message depending upon my conclusions.
>>>
>>> -Ryan
>>>
>>>
>>> Rüdiger Herrmann wrote:
>>>> Ryan,
>>>>
>>>> we will not be able to resolve the "Finalize
>>>> Display#readAndDispatch" issue in 1.2. But note that this bug is
>>>> mostly about streamlining the internal session-termination handling.
>>>>
>>>> Nonetheless shouldn't there any memory leaks if you execute the same
>>>> code in both paths.
>>>>
>>>> Could you come up with a mini-plug-in or a snippet that causes the
>>>> memory leak? Preferably open a bugzilla to attach it.
>>>>
>>>> Cheers,
>>>> Rüdiger
>>>>
>>>>
>>>>
>>>> Ryan Donnelly wrote:
>>>>> Rüdiger,
>>>>> Thanks for the information. Unfortunately, I rebuilt my app
>>>>> with the latest RAP CVS and still have the problem. Are you
>>>>> expecting to have this and its blocking issues fixed for the 1.2
>>>>> Galileo release?
>>>>>
>>>>> [3] 219789: Finalize Display#readAndDispatch
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=219789
>>>>>
>>>>> I will look into the image resource management. As I say, I
>>>>> think I am calling the same code in both exit paths, so I don't
>>>>> think that is this problem in this case, but it could certainly
>>>>> represent a different memory leak.
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ryan
>>>>>
>>>>>
>>>>> Rüdiger Herrmann wrote:
>>>>>> Ryan,
>>>>>>
>>>>>> your observations and findings are right and your code should just
>>>>>> run fine.
>>>>>> We just recently fixed two bugs ([1] and [2]) that you most likely
>>>>>> run into. The changes are in CVS HEAD and will go into the RC1 build.
>>>>>> Ideally there wouldn't be two paths and session invalidation code
>>>>>> would always be executed under the same conditions. But we aren't
>>>>>> there yet (see [1] and depedant bugs).
>>>>>> Images in RAP differ from their SWT counterparts in that they are
>>>>>> only made of a string to identify them and their width and height.
>>>>>> In addition they don't have session scope but are held in an
>>>>>> application-scoped map. The links related to images you provided
>>>>>> were about custom ways to deal with images. Naturally, you need
>>>>>> free these resources that you allocated.
>>>>>>
>>>>>> HTH
>>>>>> Rüdiger
>>>>>>
>>>>>> [1] 275332: Possible memory leak after session invalidate
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=275332
>>>>>> [2] 262220: Invalid Thread Access
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=262220
>>>>>> [3] 219789: Finalize Display#readAndDispatch
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=219789
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ryan Donnelly wrote:
>>>>>>> Hi,
>>>>>>> We have a complicated RAP application, single-sourced SWT/RWT
>>>>>>> starting from our original SWT application, running in Tomcat
>>>>>>> 6.0.18, RAP 1.2 M7, the basic structure of which I have sketched
>>>>>>> below.
>>>>>>>
>>>>>>> public int createUI()
>>>>>>> {
>>>>>>> UICallBack.activate(getClass().getName());
>>>>>>>
>>>>>>>
>>>>>>> RWT.getSessionStore().addSessionStoreListener(new
>>>>>>> SessionStoreListener() {
>>>>>>> public void beforeDestroy(SessionStoreEvent event) {
>>>>>>> if not already disposed {
>>>>>>> ...dispose shells, close db connection, etc....
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> UICallBack.deactivate(getClass().getName()); }
>>>>>>> });
>>>>>>>
>>>>>>> ...open shells, db connection, etc....
>>>>>>>
>>>>>>> ...read and dispatch loop...
>>>>>>>
>>>>>>> ...dispose shells, close db connection, etc....
>>>>>>>
>>>>>>> RWT.getRequest().getSession().setMaxInactiveInterval(1);
>>>>>>> return 0; }
>>>>>>>
>>>>>>>
>>>>>>> Running the app and exiting by returning from createUI() works
>>>>>>> fine. The problem I am trying to solve is how to clean up after a
>>>>>>> non-normal exit, caused by navigating to a new web page, hitting
>>>>>>> F5 (refresh), closing the browser, etc.
>>>>>>>
>>>>>>> From reading the newsgroup and bugzilla, I have learned the
>>>>>>> following:
>>>>>>>
>>>>>>> 1) Implement a SessionStoreListener to do your cleanup. It will
>>>>>>> get called before the session is destroyed, including:
>>>>>>>
>>>>>>> a) when a new session is created after F5 (refresh) or
>>>>>>> re-addressing the application start page
>>>>>>>
>>>>>>> b) when the session is destroyed after a timeout (e.g. after
>>>>>>> the browser is closed)
>>>>>>>
>>>>>>> 2) Upon normal exit, set the session timeout to 1 second so that
>>>>>>> the session is destroyed quickly and will not have to wait for
>>>>>>> timeout:
>>>>>>> RWT.getRequest().getSession().setMaxInactiveInterval(1);
>>>>>>>
>>>>>>>
>>>>>>> When I exit my application normally, and createUI returns, I have
>>>>>>> no problems, but when I exit through the abnormal path (F5, close
>>>>>>> browser, session timeout, etc.), I can see a memory leak in Tomcat.
>>>>>>>
>>>>>>> Suspects:
>>>>>>>
>>>>>>> 1) Disposing of SWT shells, etc. As far as i can tell I am
>>>>>>> doing this correctly, calling the same code in the
>>>>>>> SessionStoreListener which is getting called when I exit through
>>>>>>> the normal path.
>>>>>>>
>>>>>>> 2) Disposing of Images. I have seen some discussion in the
>>>>>>> newsgroup suggesting that special work may need to be done to
>>>>>>> dispose of Images. Again, as far as I can see, I am calling the
>>>>>>> same cleanup code in the SessionStoreListener that I call when
>>>>>>> exiting through the normal path.
>>>>>>>
>>>>>>>
>>>>>>> As it seems to me that, from my end, I am doing the same
>>>>>>> cleanup in the SessionStoreListener as I do in the normal app
>>>>>>> exit path, I would like to ask for some clarification as to what
>>>>>>> is going on the RAP side. Is there something more I need to call
>>>>>>> on the RAP side from the SessionStoreListener, to destroy the
>>>>>>> current thread, etc? Does the normal exit path do any cleanup
>>>>>>> after returning from createUI that it would not in the case of an
>>>>>>> abnormal exit through F5 (Refresh) or session timeout? I don't
>>>>>>> see anything obvious in the examples in the RAP source code, such
>>>>>>> as:
>>>>>>>
>>>>>>> RWTDemo
>>>>>>> RWTLifeCycle2_Test$EventProcessingOnSessionRestartEntryPoint
>>>>>>>
>>>>>>> Some relevant postings and bugs:
>>>>>>> Disposing:
>>>>>>>
>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247704
>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=253763
>>>>>>> http://dev.eclipse.org/newslists/news.eclipse.technology.rap /msg03996.html
>>>>>>>
>>>>>>>
>>>>>>> Images:
>>>>>>>
>>>>>>> news://news.eclipse.org:119/497F6B5E.8808.0090.0@kabe-farben .ch
>>>>>>> news://news.eclipse.org:119/gl9eoc$uoo$1@build.eclipse.org
>>>>>>> news://news.eclipse.org:119/e1ad67dfb09b1ae8721919cda6c56e27 $1@www.eclipse.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Any ideas are appreciated.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Ryan
|
|
|
Goto Forum:
Current Time: Mon May 13 23:05:41 GMT 2024
Powered by FUDForum. Page generated in 0.04089 seconds |
] 
Search
Help
Register
Login
Home
