Description of problem: When trying to manage or create a StorageDomain, where LUNs attached with 400+ paths, you will get an javascript error Version-Release number of selected component (if applicable): ovirt-engine-4.2.6.4-0.1.el7ev.noarch How reproducible: always Steps to Reproduce: 1. connect enough FC-devices to hosts until you have 400+ paths 2. Open New StorageDomain dialog / or modify an existing one 3. Select StorageType 'FibreChannel' Actual results: The dialog stuck and will show Javascript Error ("not responding script") after a while Expected results: A domain should be Additional info: The dialog was similar slow in RHV-4.1 UI, but on patternfly it might be worse
Greg, from the storage perspective the code works as it should and creates the dialog, I guess the massive amount of elements "chokes" the browser, what can we do to fix it?
profile it. you can see if there's some method the app is spending a ton of time in. Or you can see if there's a memory leak in that component. I can assist if someone has an environment with FC luns (or if there's a way to stub them in via database edits)
Guy, can you provide Greg with a host with 400+ paths connected?
Shani got me what I needed -- thanks!
OK, so moving to UX now to note that you are currently handling it
No corrent need from QE (Guy)
This bug has not been marked as blocker for oVirt 4.3.0. Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.
Greg, any updates?
(In reply to Michal Skrivanek from comment #14) > Greg, any updates? No.
sync2jira
This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly
The problem can be reproduced by replacing the response with static data (SanStorageModelBase.updateInternal()): - model.applyData((ArrayList<LUNs>) response.getReturnValue(), false, prevSelected, + List<LUNs> stubs = stub(500); + model.applyData(stubs, false, prevSelected, Perfomance tests results (on my laptop): 1. Chromium ~50 sec (see attachment performance_500_mocked_LUNs_chromium.webm) 2. Firefox ~22sec (see performance_500_mocked_LUNs_firefox.webm)
Created attachment 1675993 [details] performance on Chromium with static data (500 LUNs)
Created attachment 1675994 [details] performance on Firefox with static data (500 LUNs)
Created attachment 1677534 [details] offline paging added above the table
Profiling shows that rendering stage is the most time consuming. The LUNs table at Domains -> New Domain -> Fiber Channel is technically speaking a tree in which each node (row) is a GWT table component. Scenario described in this issue does not require all of the functionality (i.e. capability of displaying another GWT table as child node). However since the component is quite complex it would be time consuming to build a special purpose component only for this scenario. Due to this fact paging approach has been chosen. Solution is based on the paging code that was used so far in all tables (bottom right corner above the table). It has been extracted to allow re-use in the described scenario - see comment #25 for screen shot with the new look&feel. Note that for Fiber Channel screen the total number of items is displayed - differently then on other screens. This is caused by the fact that the underlying API does not support server side paging so all items are loaded in one request. Since the data is stored in the browser we know the size of the result set and are able to show this to the user. It's a small step towards design recommended by PatternFly 3 & 4 (see below). https://www.patternfly.org/v3/pattern-library/navigation/pagination/index.html https://www.patternfly.org/v4/design-guidelines/usage-and-behavior/pagination#main-content
Created attachment 1677572 [details] paging - perfomrance with 500 mocked LUNs on Chromium
Since it is MODIFIED already then re-targeting to 4.4.1
Verified on : rhv-release-4.4.1-3-001.noarch vdsm-common-4.40.19-1.el8ev.noarch created 300 luns with 4 paths total 1200 FC from the UI : Storage > Doamin > New > provide the current DC / Cluster / FC / Host all the Luns available on the UI 300 luns on 6 pages each page 50 luns
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 (Important: RHV Manager (ovirt-engine) 4.4 security, bug fix, and enhancement update), 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://access.redhat.com/errata/RHSA-2020:3247