Description of problem: Select the following Tabs in the Admin Portal: 1. Network Tab 2. Select the first network 3. Select "Virtual Machines" in the "sub Tab" (at the bottom) 4. go through the different Networks by clicking them 5. After some while the browser shows an "unresponsive script message" 6. Click "Stop Script" (as "Continue" just shows the message again and again 7. Select e.g. the "Hosts" Subtab (at the bottom) 9. Go back to the "Virtual Machines" Subtab (at the bottom) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Network Tab 2. Select the first network 3. Select "Virtual Machines" in the "sub Tab" (at the bottom) 4. go through the different Networks by clicking them 5. After some while the browser shows an "unresponsive script message" 6. Click "Stop Script" (as "Continue" just shows the message again and again 7. Select e.g. the "Hosts" Subtab (at the bottom) 9. Go back to the "Virtual Machines" Subtab (at the bottom) Actual results: The Virtual Machines are never shown again, just the three grey dots keep blinking there. Expected results: The "unresponsive script" should not pop up and the portal should continue working as expected (showing the Virtual Machines again). Additional info: A restart of the Browser solves the problem. Just logging out of the portal and logging in again does not help, but shows the "unresponsive script" message during login already. Shift-Reload does help, but the browser stays a lot slower and more unresponsive as before. So this might be related to BZ #1098598 somehow.
Sorry for the copy-paste mistakes. Once again therefore: Description of problem: Under some conditions the "Virtual Machine" Subtab in the "Network" tab does not show any content, but continues to show the "three grey dots". Version-Release number of selected component (if applicable): RHEV-M 3.3.4 Firefox 24.4.0 (CSB) How reproducible: Always Steps to Reproduce: 1. Network Tab 2. Select the first network 3. Select "Virtual Machines" in the "sub Tab" (at the bottom) 4. go through the different Networks by clicking them 5. After some while the browser shows an "unresponsive script message" 6. Click "Stop Script" (as "Continue" just shows the message again and again 7. Select e.g. the "Hosts" Subtab (at the bottom) 9. Go back to the "Virtual Machines" Subtab (at the bottom) Actual results: The Virtual Machines are never shown again, just the three grey dots keep blinking there. Expected results: The "unresponsive script" should not pop up and the portal should continue working as expected (showing the Virtual Machines again). Additional info: A restart of the Browser solves the problem. Just logging out of the portal and logging in again does not help, but shows the "unresponsive script" message during login already. Shift-Reload does help, but the browser stays a lot slower and more unresponsive as before. So this might be related to BZ #1098598 somehow.
The flow starts with network dialogs, so putting on network team for now to examine this issue.
I will be very surprised if this turns out to be network-specific. This reminds me of Bug 906394. I can't seem to reproduce this on my deployments (3.4/3.5), which strengthens this suspicion (as this was fixed in 3.4).
Just updating that this still exists on the master branch as well - on Firefox 22 the browser becomes sluggish, on Firefox 32 I get the non-responsive script message. Will try to pin-point the issue, fix it on master and then see where it's convenient enough to backport; not promising anything, 3.5 would be a good candidate if I can fix this soon. Then we'll see about older versions.
So I haven't been able to find the issue causing this yet, but I've all but ruled out the following theses: 1. The problem doesn't seem to be in NetworkVmListModel, it seems to be very similar to say VmListModel (which also works on pretty much the same size input). I thought it might be the sorting, which in the case of VmListModel is performed in the backend, but commenting out the sorting code in NetworkVmListModel didn't improve the situation. 2. It also doesn't seem to be in the backend query. GetVmsAndNetworkInterfacesByNetworkIdQuery seemed to be sub-optimal as it performs some artificial "joins" via Java, but simplifying the query to do nothing more than fetching the VM data and putting mock interface data in the pairs didn't significantly improve performance. 3. The last point also ruled out another theory I had, that the multiple joins producing vm_interface_view were inefficient (though all columns on which joins are performed are indexed). This leads me to believe that perhaps there's some peculiar GWT issue, unique to the compilation of this subtab's code to JavaScript. I'm not sure what's special about this subtab - it might have the biggest data set among the subtab models backed by pairs of entities (rather than pure entities). I think it might be necessary to debug the JavaScript code itself, or perform some profiling to see where time is "wasted".
Assigning back to ux where more competent frontend developers might be able to deal with it :)
The slowness is being caused by UUID (Guid class) generation for the PairQueryable's. If I comment out the generation and just use a counter, it's nice and responsive. (see attached video) In PairQueryable.java: + static private int counter = 1; public Object getQueryableId() { + return counter++; - return getMemberId(getFirst()) + '.' + getMemberId(getSecond()); } It's unclear to me why calling getMemberId causes UUID generation. Perhaps that's the bug. Assigning back to Lior, since I don't know this code. Patch attached so you can replicate.
Created attachment 952744 [details] sscreencast: nice and fast with UUID generation disabled
Created attachment 952745 [details] patch -- disable UUID generation (test only!)
Created attachment 952746 [details] screencast: nice and fast with UUID generation disabled
Greg has definitely pointed me in the right direction. The fix will be very infrastructural so needs to be properly tested, but the code changes won't be big. I think we can make it for 3.5, and I'm optimistic about backporting to 3.4. Updates to come soon...
Scale team should verify this bug, thank you.
Verified on - 3.5.0-0.21.el6ev With 2 VM pools, each pool with 200 VM's(no disks, one nic per VM).
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0158.html