| Application freezes occasionally [message #916092] |
Tue, 18 September 2012 10:13  |
Eclipse User |
|
|
|
Hello all,
we have a problem regarding RAP. Our web application freezes occasionally and we don't know how to determine the problem.
If we run the same application as an RCP application, we don't see any freezes at all.
The freezes occur at different locations and is only blocking the current session. All other sessions are running normally and if we reload the blocked session, it runs again without any problems (until the freeze happens again any time soon).
We already tried the release version of RAP 1.5 and milestone 1 of RAP 2.0, but both versions had the same problem.
We're running the web application with Tomcat 7.
We have a very big application, therefore it's not possible to post the application. We have no idea where the problem is located.
Can you give us a hint, how to trace and track down the problem?
Thank you very much in advance!
[Updated on: Mon, 24 September 2012 08:06] by Moderator |
|
|
|
|
|
|
|
|
|
| Re: Application freezes occasionally [message #1806183 is a reply to message #916092] |
Sun, 05 May 2019 07:00  |
| Eclipse User |
|
|
|
Hi,
I am currently running into this problem myself (using RAP 3.4, 3.6 and 3.8), and although I do not have a conclusive answer, I do think I have managed to home into the cause of this problem. A little background; I spawn an event every second from a microservice, which updates the GUI (a browser widget, running openlayer maps), for which I run a dedicated controller to handle the push sessions and management of the UIThread. Obviously, I also update the GUI from the various widgets.
Yesterday, after changing the controller to handle EVERY event that affects the browser (making it a sort of broker), the GUI freeze became fairly standard, and I realized that this was not due to a coding error, but rather an accident waiting to happen; up to now, my freezes would maybe occur after a few days (and were usually spotted on the production server).
After extensive testing (Display.syncExec, Display.asyncExec, etc) which did not seem to have a big effect (which makes sense because my controller is already seeing to those issues), I decided to add a requestLayout() command after every update. So far I had been using this sparsely, as I was afraid that this would cause a lot of GUI clutter. Immediately the freezing became a lot less (it hasn't gone yet), which makes me believe that the problem could lie with the buffering of changes prior to a refresh of the layout. I am not a RAP insider of course, and I do not know if my findings makes sense, but I am going to increase the amount of requestLayouts considerably, to see if the freezing diminishes further.
ADDITIONAL FINDINGS:
After a number of further tests I found out that the freezes are probably not the result of requestlayout issues, but timing in the UI Thread. The controller I developed basically register itself as a listener to external events, and starts a push session when an event is spawned. This starts a Display asyncexec, which relays the event to the widgets that actually want to do something with it.
What I found out is that timing issues DURING the relaying of events causes the browser to freeze. This can be due to long or intensive bits of code, but also something like placing a breakpoint there.
The offending code is added here for reference:
display.asyncExec( new Runnable() {
@Override
public void run() {
try {
relay( data );//Brings the data to the widgets
session.stop();
....
}
catch( Exception ex ) {
ex.printStackTrace();
}
As I am putting more activity in the relay method (or a breakpoint), the chance of a browser freeze increases significantly. syncExec has the same effect.
Hopefully this may put others on the right track to a solution, or tips for my own development would also be appreciated!
Cheers
[Updated on: Sun, 05 May 2019 16:56] by Moderator |
|
|
|
|
|
| Re: Application freezes occasionally [message #1806499 is a reply to message #1806486] |
Thu, 09 May 2019 21:54 |
| Eclipse User |
|
|
|
You need to be careful with synchronized methods and code blocks.
In general, you shouldn't be calling any methods from inside your synchronized block that are accessible to code outside your class.
My preference is to also not synchronize on objects that are accessible outside the class too - which means no synchronized methods, as they synchronize on the class or instance object.
|
|
|
Powered by
FUDForum. Page generated in 0.04095 seconds
Home