Application freezes occasionally [message #916092] |
Tue, 18 September 2012 14:13  |
Moritz Hanke Messages: 5 Registered: September 2012 |
Junior Member |
|
|
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 12:06] Report message to a moderator
|
|
|
Re: Application freezes occasionally [message #916270 is a reply to message #916092] |
Tue, 18 September 2012 20:41   |
Eclipse User |
|
|
|
I would suggest running the application in debug and when the application "freezes", suspend all the threads, find the UI thread for the frozen session and see what method it is stuck in. Perhaps you have a dead lock somewhere. Alternately you can do a thread dump with a tool like visualvm or jconsole
|
|
|
|
Re: Application freezes occasionally [message #918894 is a reply to message #918611] |
Fri, 21 September 2012 13:01   |
Moritz Hanke Messages: 5 Registered: September 2012 |
Junior Member |
|
|
Now I have made a dump. At least one session was frozen. Here are all UIThreads:
"UIThread [D3C9416047D4C852BC195473C73BC75B.node1]" - Thread t@197
java.lang.Thread.State: WAITING
at java.lang.Object.wait(Native Method)
- waiting on <1062c44> (a org.eclipse.rwt.internal.lifecycle.UIThread)
at java.lang.Object.wait(Object.java:485)
at org.eclipse.rwt.internal.lifecycle.UIThread.switchThread(UIThread.java:59)
at org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.sleep(RWTLifeCycle.java:232)
at org.eclipse.swt.widgets.Display.sleep(Display.java:1176)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:842)
at org.eclipse.jface.window.Window.open(Window.java:817)
at de.vitaphone.isp.application.ui.ISPConfiguration.login(ISPConfiguration.java:45)
at de.vitaphone.common.framework.ui.internal.Application.start(Application.java:35)
at org.eclipse.rap.ui.internal.application.EntryPointApplicationWrapper.createUI(EntryPointApplicationWrapper.java:38)
at org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.createUI(RWTLifeCycle.java:177)
at org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadController.run(RWTLifeCycle.java:289)
at java.lang.Thread.run(Thread.java:662)
at org.eclipse.rwt.internal.lifecycle.UIThread.run(UIThread.java:102)
Locked ownable synchronizers:
- None
"UIThread [26D0ACE921D64EA06B5739AB0623EA22.node1]" - Thread t@171
java.lang.Thread.State: WAITING
at java.lang.Object.wait(Native Method)
- waiting on <3c9590> (a org.eclipse.rwt.internal.lifecycle.UIThread)
at java.lang.Object.wait(Object.java:485)
at org.eclipse.rwt.internal.lifecycle.UIThread.switchThread(UIThread.java:59)
at org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.sleep(RWTLifeCycle.java:232)
at org.eclipse.swt.widgets.Display.sleep(Display.java:1176)
at org.eclipse.ui.application.WorkbenchAdvisor.eventLoopIdle(WorkbenchAdvisor.java:361)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2734)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2694)
at org.eclipse.ui.internal.Workbench.access$5(Workbench.java:2530)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:702)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:685)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:157)
at de.vitaphone.common.framework.ui.internal.Application.start(Application.java:38)
at org.eclipse.rap.ui.internal.application.EntryPointApplicationWrapper.createUI(EntryPointApplicationWrapper.java:38)
at org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.createUI(RWTLifeCycle.java:177)
at org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadController.run(RWTLifeCycle.java:289)
at java.lang.Thread.run(Thread.java:662)
at org.eclipse.rwt.internal.lifecycle.UIThread.run(UIThread.java:102)
Locked ownable synchronizers:
- None
"UIThread [2E5B310C0E9B0D57DFEC887315FB66AB.node1]" - Thread t@168
java.lang.Thread.State: WAITING
at java.lang.Object.wait(Native Method)
- waiting on <10fb87d> (a org.eclipse.rwt.internal.lifecycle.UIThread)
at java.lang.Object.wait(Object.java:485)
at org.eclipse.rwt.internal.lifecycle.UIThread.switchThread(UIThread.java:59)
at org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.sleep(RWTLifeCycle.java:232)
at org.eclipse.swt.widgets.Display.sleep(Display.java:1176)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:842)
at org.eclipse.jface.window.Window.open(Window.java:817)
at de.vitaphone.isp.application.ui.ISPConfiguration.login(ISPConfiguration.java:45)
at de.vitaphone.common.framework.ui.internal.Application.start(Application.java:35)
at org.eclipse.rap.ui.internal.application.EntryPointApplicationWrapper.createUI(EntryPointApplicationWrapper.java:38)
at org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.createUI(RWTLifeCycle.java:177)
at org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadController.run(RWTLifeCycle.java:289)
at java.lang.Thread.run(Thread.java:662)
at org.eclipse.rwt.internal.lifecycle.UIThread.run(UIThread.java:102)
Locked ownable synchronizers:
- None
"UIThread [07D87F7551A46D53E16E660D98634839.node1]" - Thread t@167
java.lang.Thread.State: WAITING
at java.lang.Object.wait(Native Method)
- waiting on <18d1669> (a org.eclipse.rwt.internal.lifecycle.UIThread)
at java.lang.Object.wait(Object.java:485)
at org.eclipse.rwt.internal.lifecycle.UIThread.switchThread(UIThread.java:59)
at org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.sleep(RWTLifeCycle.java:232)
at org.eclipse.swt.widgets.Display.sleep(Display.java:1176)
at org.eclipse.ui.application.WorkbenchAdvisor.eventLoopIdle(WorkbenchAdvisor.java:361)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2734)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2694)
at org.eclipse.ui.internal.Workbench.access$5(Workbench.java:2530)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:702)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:685)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:157)
at de.vitaphone.common.framework.ui.internal.Application.start(Application.java:38)
at org.eclipse.rap.ui.internal.application.EntryPointApplicationWrapper.createUI(EntryPointApplicationWrapper.java:38)
at org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.createUI(RWTLifeCycle.java:177)
at org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadController.run(RWTLifeCycle.java:289)
at java.lang.Thread.run(Thread.java:662)
at org.eclipse.rwt.internal.lifecycle.UIThread.run(UIThread.java:102)
Locked ownable synchronizers:
- None
[Updated on: Fri, 21 September 2012 13:02] Report message to a moderator
|
|
|
Re: Application freezes occasionally [message #921559 is a reply to message #918894] |
Mon, 24 September 2012 08:15   |
|
Hi Moritz,
at least this part of the thread dump looks completely sane. All
UIThreads are waiting in Display#sleep for the next request.
Could you describe the symptoms of this freeze? Does the browser send a
request that does not get a response? In this case it would also be
interesting to look at the particular request thread. It's not a
UIThread but one from the servlet container's thread pool. Could you
provide the entire thread dump?
Regards, Ralf
--
Ralf Sternberg
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
|
Re: Application freezes occasionally [message #921766 is a reply to message #921559] |
Mon, 24 September 2012 12:04   |
Moritz Hanke Messages: 5 Registered: September 2012 |
Junior Member |
|
|
Hi Ralf,
here is the full dump. Yes I think that the browser send a request and wait for a request. When we use a loadbalancer between the browser and the tomcat, you can see a error log in the LB when you close the browser.
In the first post I have made a mistake: We use Tomcat 7.
Regards, Moritz
[Updated on: Mon, 24 September 2012 12:28] Report message to a moderator
|
|
|
|
|
Re: Application freezes occasionally [message #1806183 is a reply to message #916092] |
Sun, 05 May 2019 11: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 20:56] by Moderator Report message to a moderator
|
|
|
Re: Application freezes occasionally [message #1806193 is a reply to message #1806183] |
Sun, 05 May 2019 20:37   |
Eclipse User |
|
|
|
This is where you need to monitor the traffic in your browser dev console.
When the problem occurs, you'll be able to see if it's due to a request failing, returning bad data or not returning at all.
If there is an active request with the server you can then do a thread dump to see where the problem is.
Why is the run method synchronised? There is no valid reason for it to be.
|
|
|
|
Re: Application freezes occasionally [message #1806486 is a reply to message #1806194] |
Thu, 09 May 2019 17:04   |
Eclipse User |
|
|
|
As it turns out, the cause of my browser freeze was due to a synchronized method that had been caught up in a race condition. The method ( a notifyListener method) was called once and worked fine, but then one of the registered listeners indirectly called it again. The result was a black hole of coding due to a deadlock.
Long story short... this was no bug in eclipse RAP, but my own mistake.
|
|
|
Re: Application freezes occasionally [message #1806499 is a reply to message #1806486] |
Fri, 10 May 2019 01: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.04526 seconds