| 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 #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 |
Kees Pieters
Messages: 10
Registered: October 2015 |
Junior Member |
|
|
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] Report message to a moderator |
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02823 seconds
] 
Search
Help
Register
Login
Home
