This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 697850

Summary: Child Resources subtab refreshes twice
Product: [Other] RHQ Project Reporter: John Mazzitelli <mazz>
Component: Core UIAssignee: Jay Shaughnessy <jshaughn>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: high    
Version: 4.0.0.Beta1CC: ccrouch, hrupp, jshaughn
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugzilla.redhat.com/show_bug.cgi?id=704742
Whiteboard:
Fixed In Version: 4.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-03 12:57:00 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 705059, 715334    

Description John Mazzitelli 2011-04-19 08:58:14 EDT
Go to any resource that has children. Specifically navigate to its Inventory > ChildResources subtab and notice the table refreshes twice in quick succession.

We don't want to refresh or load the table twice everytime we go to the child resources page.
Comment 1 Jay Shaughnessy 2011-04-20 09:12:27 EDT
I'm not sure there are really two loads here.

When switching subtabs I only see one call to fetch the children (findResourceCompositesByCriteria()).  When navigating directly (via, say, the back button or a browser url when not currently in the resource detail view) there are in fact two calls to findResourceCompositesByCriteria(). But, this is expected.  We always call findResourceCompositesByCriteria() when loading a resource detail view, that call loads the target resource.  The second call then loads the children.
Comment 2 Jay Shaughnessy 2011-04-20 17:42:43 EDT
paraphrased from mazz: "the issue is a visible redraw of the list grid contents. Whether or not this is tied to an unnecessary db fetch is not known. The spinner spins, though.  But, at last try it did not reproduce."

I suggest we drop prio on this and move to jon3 from rhq4.  Stopping work for now.
Comment 3 Charles Crouch 2011-04-25 11:48:33 EDT
Unassigning as work is stopped
Comment 4 Ian Springer 2011-05-17 16:33:17 EDT
Note, this issue actually affects all subtabs (or all that implement RefreshableView, which may be all of them). There is a separate BZ for the same issue on the Configuration>Current subtab (https://bugzilla.redhat.com/show_bug.cgi?id=704742), which is a bit different than most subtabs, because it is not a Table.
Comment 5 Jay Shaughnessy 2011-05-19 09:53:22 EDT
commit ecd63ba59b3e985481dc76de3044dfad656a8dd2
Author: Jay Shaughnessy <jshaughn@redhat.com>
Date:   Wed May 18 15:22:25 2011 -0400

For the resource and group detail views (The two level tab views) ensure
that for RefreshableViews the subtab canvas is not rendered until after
refresh() is called on the canvas.  This allows the refresh method to
clear stale data from an existing canvas before initiating the async pull
of new data, preventing the user from briefly seeing the stale data and
then having the refresh kick in (which can look a lot like an unnecessary
refresh)

For Tables this works well without any changes to the refresh() method.
That's because the ds invalidateCache method clears the grid. Other
views may have to ensure the canvas is presentable in the refresh impl.
This commit includes a change like this for the current resource config view.
Note that the other 3 config views (resPlugin, groupPlugin, groupConf)
already handled this as needed.
Comment 6 Mike Foley 2011-05-24 16:01:18 EDT
verified.
Comment 7 Heiko W. Rupp 2013-09-03 12:57:00 EDT
Bulk closing of old issues that are in VERIFIED state.