| UI Freeze with RAP [message #1850958] |
Wed, 23 March 2022 11:29  |
 Kees Pieters
Messages: 10
Registered: October 2015 |
Junior Member |
|
|
My question is not a specific bug report, but I am trying to find a solution to a UI freeze problem, and could use some help.
This is the situation:
I have a RAP Application, in which I display an openlayers map in a Browser Widget. The browser communicates with a number of REST services and displays the route of a small autonomous vessel on the map. The map is updated by external thread, and therefore a push session has been implemented in order to update the map, when an external event is spawned. All this works perfectly fine.
The problem is that the responsiveness of the web page quickly deteriorates and after a few minutes also seems to freeze. For a long time i thought that the problem could be pinpointed to the openlayers map, but I am currently starting to believe that it may be releated to the way that I am using the push session mechanism, and I would like to verify this here. Profiling the browser page has demonstrated that the CPU thread is very busy when the freeze happens, and that it can take more than half a minute to respond.
The idea that I am currently exploring is that in my case there a multiple events in the RAP entry point that use the push session mechanism and call the session.start() method after the UI is updated. Some of these session.start() calls don't result in an update action, which could result in a build up of overhead in the javascript code that RAP generates..
My question is whether this train of thought is correct, or the push mechanism is such that it does not slow down UI performance even when a lot of push sessions are used.
Any thoughts would be greatly appreciated!
|
|
|
| Re: UI Freeze with RAP [message #1851034 is a reply to message #1850958] |
Fri, 25 March 2022 10:11  |
Dmitry Dukhov
Messages: 180
Registered: February 2013 |
Senior Member |
|
|
I had problems like this (if I understand your problem correctly). For example, I don't update the view for a table if the table hasn't changed, or for charts. don't run a widget update unless you've received the view data earlier on a separate non-display thread. One display thread can stop other display threads if it hangs( Set break timeout for display thread.) I think I said commonplace ... but in my case these tricks help me for view big online dashboard, realtime update a lot of tables, charts and etc. inside many tabs without freeze for interface. Divide threads by 2 1. standard thread for data 2. thread with push sessions for view data (without requests)
[Updated on: Fri, 25 March 2022 10:38] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.02006 seconds
] 
Search
Help
Register
Login
Home
