Bug 847014 - Resource tree not complete when more than 200 children
Resource tree not complete when more than 200 children
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
All All
medium Severity urgent (vote)
: ---
: RHQ 4.5.0
Assigned To: Jay Shaughnessy
Mike Foley
: 753141 848851 (view as bug list)
Depends On: 784571 848851
Blocks: 849761
  Show dependency treegraph
Reported: 2012-08-09 09:08 EDT by Jay Shaughnessy
Modified: 2013-09-01 06:15 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 784571
Last Closed: 2013-09-01 06:15:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Comment 1 Jay Shaughnessy 2012-08-09 09:25:27 EDT
master commit 396b48fde3613c359b49ca4b776ee18fa39f3865

Allow an unlimited number of children when expanding the tree node. Although
this may create a large vertical expansion, it may also be what the
user wants.  See BZ comments for more on the approach and alternatives
but basically, take this [easy] approach until it's clear that users, or UX,
want something else.
Comment 2 Jay Shaughnessy 2012-08-16 11:12:09 EDT
*** Bug 848851 has been marked as a duplicate of this bug. ***
Comment 3 Jay Shaughnessy 2012-08-16 12:50:10 EDT
master commit 30a6818e7ae101dc8df7edc198c5ee9ac790683e

We decided not to allow an unlimited number of child resources be returned
when expanding a node in the tree.  But there are major problems with
simply limiting the children to 200.  This is what we do today, and the
results are unordered. Meaning you can lose any number of resources of
any types and it is not possible to know what you are missing. And we don't
indicate that the tree is incomplete. If we add ordering (alphabetical by
resource name) you still lose any number of resources, but always the same
ones.  In this way it is much easier to realize that you are missing
child resources (and/or entire child types) because the resources returned
obviously stop as some lexigraphical point.

Still, we don't want to allow an unbounded fetch in the GUI.  The solution
here is to move the unbounded fetch to the server side and to introduce
SLSB support to prune the results and return the pruned child set.  In this
way we can limit the max child resources while returning a much more
reasonable resource set.

The way it works is as follows: There are two variable in use:

Will not return more than this number of resources.  If the original fetch
exceeds maxResources then maxResourcesByType will be enforced.  If, after
trimming by type, maxResources is still exceeded, then the tail
resources (assuming a sorted set) will be removed to enforce the limit.
If <=0 the default (currently set to 1000) will be used.

If maxResources is exceeded by the initial result set then members of each
type will be trimmed down to meet this limit.
If <=0 the default (currently set to 200) will be used.

The defaults may change after this check-in based on testing results. The
GUI will not set these values in the fetch, so the defaults will be applied.

The default values can be overriden (and applied to all fetches/sessions) by
setting the following system properties (in rhq-server.properties and restarting):

So, this allows us to:
- Avoid an unbounded fetch.
- Have any distribution of child resources of various types as long as the
  maxResources limit is not exceeded.
- Apply an even and understandable pruning when necessary.

It does not yet allow us to indicate in the tree which resource types have
been pruned.  This will be a future enhancement and tracked as
Comment 4 Jay Shaughnessy 2012-08-16 16:17:56 EDT
Test Notes:

See the comments in bug 784571.
Comment 5 Jay Shaughnessy 2012-08-20 14:32:47 EDT
*** Bug 753141 has been marked as a duplicate of this bug. ***
Comment 6 Heiko W. Rupp 2013-09-01 06:15:08 EDT
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.

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