Red Hat Bugzilla – Full Text Bug Listing
|Summary:||clicking the Update Membership button for a large compat group causes "Failed to fetch Resource Group" RPC timeout error and the modal window remains blank|
|Product:||[Other] RHQ Project||Reporter:||Ian Springer <ian.springer>|
|Component:||Core UI||Assignee:||Ian Springer <ian.springer>|
|Status:||CLOSED WONTFIX||QA Contact:||Mike Foley <mfoley>|
|Version:||4.0.1||CC:||ccrouch, hrupp, jshaughn|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-02-26 16:24:46 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||678340, 717358, 722548, 730796, 735475|
Description Ian Springer 2011-08-30 13:13:22 EDT
The compat group contained 10,000 member Resources. After clicking the Update Membership button on the Inventory>Members subtab, I waited a few minutes for the modal to finish drawing but it never did, so I eventually clicked the close icon at the upper right corner of the modal to close it.
Comment 1 Ian Springer 2011-08-30 17:12:50 EDT
For a group with 1,000 members, the modal takes about 6 seconds to load, so you would think a 10,000 member group would take around 60 seconds. I thought I waited that long but perhaps not.
Comment 2 Ian Springer 2011-09-15 16:00:45 EDT
Users will usually probably use dynagroups to create and update large groups, rather than using the group create/update wizards. That said, the poor performance for the selector component is a result of the fact that it loads the entire set of available and assigned items into memory (i.e. the data is not paged) in order to allow moving of items back and forth between the two sets purely on the client side. There are a couple things we could do to make this better: 1) redesign the selector widget, so it does not need to preload all of the data. this would not be trivial, and might require totally redesigning the GUI for the widget. 2) make sure to only fetch a lightweight version of the items in the lists. For example, for Resources, we could get by with just the id, name, ancestry, and type fields, but we are currently fetching many other fields.
Comment 3 Ian Springer 2011-10-21 11:47:28 EDT
The selector component now limits the number of available items it loads to a maximum of 100, but it still always loads the entire set of assigned items.
Comment 4 Jay Shaughnessy 2013-02-26 16:24:46 EST
Closing this given the limiting approach. Further work here should be initiated by problems due to the latest approach. Filters should be added, if missing, to selectors that can't fit a reasonable set into the selector window.