Bug 734527 - 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
clicking the Update Membership button for a large compat group causes "Failed...
Status: CLOSED WONTFIX
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
4.0.1
Unspecified Unspecified
medium Severity high (vote)
: ---
: ---
Assigned To: Ian Springer
Mike Foley
:
Depends On:
Blocks: jon3 jon30-perf rhq-gui-timeouts rhq41-ui rhq-uxd
  Show dependency treegraph
 
Reported: 2011-08-30 13:13 EDT by Ian Springer
Modified: 2013-08-05 20:40 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-26 16:24:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
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.

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