Bug 1155992 - ui not responding sporadically
Summary: ui not responding sporadically
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal
Version: 3.5.0
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
: 3.5.0
Assignee: Alexander Wels
QA Contact: Eldad Marciano
URL:
Whiteboard: ux
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-23 10:59 UTC by Eldad Marciano
Modified: 2015-02-16 13:35 UTC (History)
13 users (show)

Fixed In Version: org.ovirt.engine-root-3.5.0-20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-16 13:35:09 UTC
oVirt Team: ---


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 34570 master MERGED webadmin: UI plugin event handler Never
oVirt gerrit 34682 ovirt-engine-3.5 MERGED webadmin: UI plugin event handler Never
oVirt gerrit 34703 master MERGED webadmin: Main tab presenter loading Never
oVirt gerrit 34707 ovirt-engine-3.5 MERGED webadmin: Main tab presenter loading Never
Red Hat Bugzilla 1148095 None None None Never

Internal Links: 1148095

Description Eldad Marciano 2014-10-23 10:59:56 UTC
Description of problem:
i have installed rhevm vt7,
Once intallaiton completed i logged in into engine in trying to create new dc,cluster,hosts

there is no response, when clicking on objects at the ui like cluster tab search panel configuration panel and any other object  

suddenly (after few sec Infinitely my mouse clicks come back to live)

reproduced in chrome and Firefox.

priority + further investigation required

Version-Release number of selected component (if applicable):
3.5 VT7

How reproducible:
60%

Steps to Reproduce:
1. install VT7
2. UI clicks

Actual results:
Infinitely, UI clicks no responding (after login)

Expected results:
stable UI availability.

Additional info:

Comment 1 Einav Cohen 2014-10-23 12:18:37 UTC
@Eldad - is this something that did not happen in earlier "vt" versions? i.e. is that a "new" issue in vt7?

if not: this sounds like the manual-tests-side of bug 1148095. 

need to keep in mind that the login process (i.e. from clicking on 'login' in the login-page until main view is loaded) has shortened dramatically, as we moved to sort-of a "lazy-loading" mechanism (i.e. instead of loading the entire application in advance, modules are loaded on-demand). 

we need to understand if this is a real user-experience issue (i.e. is user experience is completely unbearable), or if the current behavior is reasonable, especially given that the login process has shortened dramatically. 

thanks.

Comment 2 Eldad Marciano 2014-10-23 12:53:38 UTC
Einav,
since it's the first time i'm installing VT version. i can't guarantee that.
but i used to work with 3.5 master (ovirt) and i faced that issue as well.

Comment 3 Einav Cohen 2014-10-23 13:01:32 UTC
(In reply to Eldad Marciano from comment #2)
> Einav,
> since it's the first time i'm installing VT version. i can't guarantee that.
> but i used to work with 3.5 master (ovirt) and i faced that issue as well.

thanks, that makes sense. it practically implies that this happened in vt versions earlier than vt7, which further validates everything that I have described in comment #1.

Comment 4 Alexander Wels 2014-10-23 14:32:57 UTC
Can someone please make a video that demonstrates this issue. I am completely unable to reproduce the problem. Also can I get the following information:

1. The specs of the machine running the browser (Mem, cpu, browser).
2. The specs of the machine running the engine (Mem, cpu, can it resolve itself, aka is the machine in DNS, or in /etc/hosts).
3. Can I have access to the engine that is giving the problem, so I can see if I can reproduce it there.

Comment 5 Barak 2014-10-23 15:42:13 UTC
Eldad,

What was the scale this issue was reported on (#of hypervisors & #of VMs) ?
Or was it on a clean install ?

Comment 6 Eldad Marciano 2014-10-26 15:00:56 UTC
not related to scale since it's from scratch setup

Comment 7 Eldad Marciano 2014-10-26 15:07:02 UTC
(In reply to Alexander Wels from comment #4)
> Can someone please make a video that demonstrates this issue. I am
> completely unable to reproduce the problem. Also can I get the following
> information:
> 
> 1. The specs of the machine running the browser (Mem, cpu, browser).
> 2. The specs of the machine running the engine (Mem, cpu, can it resolve
> itself, aka is the machine in DNS, or in /etc/hosts).
> 3. Can I have access to the engine that is giving the problem, so I can see
> if I can reproduce it there.

1. specs of the machine running the browser(4 cores, 8GB, chrome + firefox)
2. specs of the machine running the engine (24 cores, 64GB /etc/hosts:
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
3. engine access:
host: host05-rack04.scale.openstack.engineering.redhat.com
pass: will sent by email.

if you can't reproduced this issue, i'll record a video.

note - that host located in phoenix.

Comment 8 Einav Cohen 2014-10-27 13:59:44 UTC
@Arthur: Can you please contact Eldad in order to obtain the password of the setup mentioned in Comment #7 and try this out, and report back here your insights?

@Alexander: any thoughts/suggestions?

Comment 9 Alexander Wels 2014-10-27 17:37:31 UTC
@Einav,

I was able to log into the machine and look at what is going on, I can reproduce the issue without problem on the machine there. I can also see the reason why things are so slow. My fix was to not load all the presenters at login, in essence lazy loading all the presenters. When you look at the network traffic you can see this changed from 3.4 to 3.5 because there are not 100+ calls XXX.cache.js when you log in.

However when I look at the network traffic for host05-rack04.scale.openstack.engineering.redhat.com I see a normal login, but then something triggers the loading of all the presenters and I see 100+ calls to XXX.cache.js. If I wait for all of them to end, and I click around everything is snappy, but while loading everything is very slow.

When I do the same thing on my local master, that doesn't happen, after the VMs load, nothing happens until I select one, and it loads half a dozen or XXX.cache.js files (which is expected). I will create a 3.5 environment to see if I can reproduce that behavior there.

Also note the engine in that machine is using huge amounts of memory:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                                                 
 3973 root      20   0 15436 1732  944 R  1.0  0.0   0:00.14 top                                                                                                                                                                     
 2959 ovirt     20   0 17.0g 1.6g  24m S  0.7  2.5   6:43.22 java

Comment 10 Einav Cohen 2014-10-28 12:06:20 UTC
(In reply to Alexander Wels from comment #9)
> @Einav,
> 
> I was able to log into the machine and look at what is going on, I can
> reproduce the issue without problem on the machine there. I can also see the
> reason why things are so slow. My fix was to not load all the presenters at
> login, in essence lazy loading all the presenters. When you look at the
> network traffic you can see this changed from 3.4 to 3.5 because there are
> not 100+ calls XXX.cache.js when you log in.
> 
> However when I look at the network traffic for
> host05-rack04.scale.openstack.engineering.redhat.com I see a normal login,
> but then something triggers the loading of all the presenters and I see 100+
> calls to XXX.cache.js. If I wait for all of them to end, and I click around
> everything is snappy, but while loading everything is very slow.
> 
> When I do the same thing on my local master, that doesn't happen, after the
> VMs load, nothing happens until I select one, and it loads half a dozen or
> XXX.cache.js files (which is expected). I will create a 3.5 environment to
> see if I can reproduce that behavior there.
> 
> Also note the engine in that machine is using huge amounts of memory:
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND        
> 
>  3973 root      20   0 15436 1732  944 R  1.0  0.0   0:00.14 top            
> 
>  2959 ovirt     20   0 17.0g 1.6g  24m S  0.7  2.5   6:43.22 java

Alexander, I just noticed that in Comment #2, Eldad claims that he faced this issue when working with ovirt's master as well; so while it seems that there is an issue with the RHEV ui-plugin, there may be an additional issue that is relevant for both ovirt and RHEV (not sure whether Eldad tested ovirt master before or after [1] was merged; I assume after, just because [1] was merged quite a long time ago, so worth looking into it). 

[1] http://gerrit.ovirt.org/#/c/30710/

Comment 11 Alexander Wels 2014-10-29 19:14:12 UTC
@Eldad,

Can you provide me a master or oVirt 3.5 machine that I can look at that is giving you trouble. There is a known issue with some UI plugins that can cause a bunch of presenters to be loaded at once, which is the cause of the slowdown in RHEV. However I am unable to create on a stock oVirt without plugin.

Comment 12 Eldad Marciano 2014-10-30 12:28:11 UTC
i have rhevm 3.5 VT7 running.
if you need i can run for ovirt master 
ping me ON IRC when able (emarcian)

Comment 15 Alexander Wels 2014-11-06 19:41:18 UTC
@Eldad,

Apparently the fix that I showed you the other day did NOT make it into VT9, but will be in VT10.

Comment 16 Einav Cohen 2014-11-24 13:45:11 UTC
not sure why didn't move automatically to ON_QA -> moving manually.

Comment 17 Scott Herold 2014-12-17 03:55:26 UTC
clearing needinfo flags as this is now on_qa

Comment 18 Eldad Marciano 2014-12-23 15:52:13 UTC
verified on VT13.1


Note You need to log in before you can comment on or make changes to this bug.