Bug 1098598

Created attachment 896460 [details]
screenshot displaying error

sounds related to bug 1054242. 
Evgheni: which FF24 exact version are you using? 
can you please make sure that you are using the one distributed via the errata linked to bug 1054242?

Einav, I'm using the latest firefox build available in the repo. This new BZ was opened specifically because in BZ#1054242 it was recommended to open a new bug about performance issues. The memory leak seems to have been fixed, but I still see the stuck script warning.

# rpm -qi firefox
Name        : firefox                      Relocations: (not relocatable)
Version     : 24.5.0                            Vendor: Red Hat, Inc.
Release     : 1.el6_5                       Build Date: Tue 22 Apr 2014 04:31:09 PM CEST
Install Date: Wed 30 Apr 2014 11:24:03 AM CEST      Build Host: x86-026.build.eng.bos.redhat.com
Group       : Applications/Internet         Source RPM: firefox-24.5.0-1.el6_5.src.rpm
Size        : 83232863                         License: MPLv1.1 or GPLv2+ or LGPLv2+
Signature   : RSA/8, Mon 28 Apr 2014 08:52:43 AM CEST, Key ID 199e2f91fd431d51
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://www.mozilla.org/projects/firefox/
Summary     : Mozilla Firefox Web browser
Description :
Mozilla Firefox is an open-source web browser, designed for standards
compliance, performance and portability.

Thanks, Evgheni. What happens when you are trying to run the RHEV-M GUI on FF17 on the same client / another identical client?
[need to understand if this is a FF regression, or if this always have been the state of the GUI for such client]?

Einav,just checked, I also get the error on FF17:


------------
A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

Script: https://<hostname>/webadmin/webadmin/703514569DB8B555E64E057CF39EEA11.cache.html:10762
------------

The steps were (on the same RHEL 6.5 machine):
# yum downgrade firefox-17.0.10-1.el6_4
# useradd ff17user
# passwd  ff17user

Then I took the "sux" shellscript from debian to save myself from logging into new sessions and ran firefox from there:

$ sux ff17user
$ firefox

The first attempt to log in did not display the warning, but logging out and then back in did the trick.

Thanks, Evgheni. 

- IIUC, the problem is just with the initial loading of the application. i.e. when refreshing the page, the problem goes away, correct?

- Can you please try testing RHEV-3.4 and also ovirt-3.5.0-alpha? There is a chance that after the frontend refactoring + PatternFly adoption that we did, initial-loading performance has changed (hopefully improved).

I will try to test this out, however I do not remember any versions of oVirt displaying this warning, even when corresponding RHEV versions of RHEV did so.

Just tried a 3.4 Admin Portal and the warning is still there for me

since this is not a regression (happening as early as 3.2), I am pushing for 3.6 for now. I am not sure if we will be able to do anything about it - maybe the lazy initialization approach [1] will help?

also: we never outlined minimal client requirement (though "core2duo CPU and 4 gigs of RAM" sounds reasonable for a client). 

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

I still get the warning each day on my RHEL6 machine when opening a 3.4 portal.

Maybe I've described what happens but let me reiterate:
1) I log in (no matter if local or LDAP user is used)
2) I get the warning message
3) I press the "stop script" button
4) I am left staring at a gray page and URL https://<rhevm>/ovirt-engine/webadmin/?locale=en_US#login in the address bar
5) if I refresh the page nothing happens
6) if I remove "#login" from the URL, I am forwarded to the portal without being prompted for a password again. This means authentication happens successfully, and there's something after it which freezes the process.

FYI I upgraded the my test RHEL desktop to an HP Z400 (8G RAM, quad core Xeon W3550, nvidia quadro FX 380 & 304 series driver) and still see warning popups daily.

So faster hardware made no difference in my case.

Evgheni,

I don't think getting faster hardware will help much, getting faster hardware on the engine and getting a faster network connection will help. The problem basically is that the application tries to open 80+ connections at once to download a piece of code to execute. Browsers have a limit of the number of concurrent connections allowed. So each connection after the first 4-8 has to wait for the previous one the be done before proceeding, this can take some time and causes the popup to appear.

Depending on the browser this limit is somewhere between 4 and 8. You could try tweaking the number to be higher in the undocumented settings of firefox to see if it help, but I doubt it.

For 3.5 we have solved the issue of it opening so many connections at the same time so it should be much better.

Just tried to open an oVirt 3.5 portal and indeed the message does not seem to show up after re-login. The interface freezes for 20 seconds after clicking on anything for the first time, but that's probably something unrelated.

Let's wait till 3.5 is released to confirm the issue is completely gone and then  close this BZ.

Can you try to recreate it on 3.5?

(In reply to Yaniv Dary from comment #35)
> Can you try to recreate it on 3.5?

I cannot reproduce it on 3.5.0 nor 3.5.1 (vt14).
I used RHEL 6 client with firefox-31.5.0-1.el6_6.x86_64 and 4 GB RAM (2,9GB free).
I logged into Webadmin portal, worked in it for a while, then logged out & logged in again. I repeated it three times and didn't encountered any "unresponsive script" dialog.

Closing due to comment #34 and comment #36.