I have some dialogs where I want to avoid closing (for example because input is made, but not saved). In this case I show a MessageBox to the users to inform them, which I think is very common.
If a user closes the brosertab showing such a dialog (the MessageBox is not shown at that moment) and keep the JSESSIONID alive (which is the case if you close only a tab and not the whole browser) and later calls the same thinwire application again the cpu usage on the server side raises 99% and more and never goes lower.
The same happens if the thinwire application is called a second time in another tab while such a dialog is open in one tab of the browser.
There is no difference if I override the setVisible() method to catch the do-not-close condidtion or if I use a PropertyChangeEvent for the PROPERTY_VISIBLE property.
Is there any way for my application to detect that thinwire is in a „force-close“ state so that I can skiping the part that blocks the closing? Or has the framework any way to detect endless loops of that kind?
I filed a bug (1889507) to document this behaviour and to provide a testcase (with more detailed test-results in the source).
Tested with firefox on windows and linux (but I think the browser version is not important) as broser and tomcat 5.5 für windows and linux using thinwire 1.2 revision 641.
Any suggestions how to aviod this?
thanks
gerhard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have some dialogs where I want to avoid closing (for example because input is made, but not saved). In this case I show a MessageBox to the users to inform them, which I think is very common.
If a user closes the brosertab showing such a dialog (the MessageBox is not shown at that moment) and keep the JSESSIONID alive (which is the case if you close only a tab and not the whole browser) and later calls the same thinwire application again the cpu usage on the server side raises 99% and more and never goes lower.
The same happens if the thinwire application is called a second time in another tab while such a dialog is open in one tab of the browser.
There is no difference if I override the setVisible() method to catch the do-not-close condidtion or if I use a PropertyChangeEvent for the PROPERTY_VISIBLE property.
Is there any way for my application to detect that thinwire is in a „force-close“ state so that I can skiping the part that blocks the closing? Or has the framework any way to detect endless loops of that kind?
I filed a bug (1889507) to document this behaviour and to provide a testcase (with more detailed test-results in the source).
Tested with firefox on windows and linux (but I think the browser version is not important) as broser and tomcat 5.5 für windows and linux using thinwire 1.2 revision 641.
Any suggestions how to aviod this?
thanks
gerhard