Usage of implicitResources in ClusterManagerBean#buildQuery

Andreas Veithen andreas.veithen at gmail.com
Wed Oct 10 07:06:30 UTC 2012


John,

What you are saying makes perfect sense _in general_, but I have a
doubt about that _particular_ query.

As far as I can see, the code (actually
ClusterManagerBean#getAutoClusterResources) executing that query gets
a cluster key as input and is expected to return the corresponding
resources. In my case, the cluster key refers to a group of WebSphere
servers and its hierarchy is ("JVM", "java.lang:type=Memory",
"java.lang:name=MarkSweepCompact,type=GarbageCollector"). If I
understand the generated query correctly, it searches for resources
satisfying all of the following conditions:

* The key of the resource is
'java.lang:name=MarkSweepCompact,type=GarbageCollector'.
* The resource key of the parent is 'java.lang:type=Memory '.
* The resource key of the grandparent is 'JVM'.
* The grandgrandparent is an implicit member of the group of WebSphere servers.

That makes sense, except for the usage of the implicit membership in
the last condition. In fact, the grandgrandparent can only be a root
level member (a WebSphere server in my case), i.e. it is always part
of the explicit membership. So why does the query use the implicit
membership? Are there any cases where that condition in the query is
satisfied by an implicit member that is not an explicit member?

There is another way to look at that question: I understand that the
implicit membership is used in authorization checks, but what does
ClusterManagerBean#getAutoClusterResources have to do with
authorization?

Andreas

On Tue, Oct 9, 2012 at 5:11 PM, John Mazzitelli <mazz at redhat.com> wrote:
> Implicit members are used for recursive groups. IIRC, if you have a non-recursive group (doesn't matter if its a mixed group or compatible group), the implicit group membership will be the same as the explicit group membership.
>
> If you have a recursive group, it means the members of the group will not only be the resources you explicitly put into the group (hence the name "explicit members") but it also means all of the children of those resources will also be automatically (implicitly) added as members of that group (hence the name "implicit members").
>
> Recursive groups are normally only used for authorizing access to its members (hence the comment you see). For example, if you want users in the role "app server admins" to have access to your app server resources, you can just create a group of app server resources, make it recursive, and give access to that group to your "app server admins" role. Now the users in that role can access any resource associated with the app servers (including their children resources like datasources, web apps, etc).
>
> To perform authorization checks, RHQ checks the implicit resources because if you are a user trying to look at a webapp resource, for example, RHQ needs to not only look at the explicit members of that group but must also see if a group you have access to has that resource in its implicit members as well. So it just checks implicit membership (note: explicit resources are also in the implicit resource list - in other words, the explicit resource list is a subset of the implicit resource list - for non-recursive groups, explicit resource set is the same as the implicit resource set).
>
> ----- Original Message -----
>> ClusterManagerBean#buildQuery contains the following code:
>>
>>         // this is an authorization-related query, so use
>> implicitResource (not explicitResources)
>>         if (1 == size) {
>>             query
>>                 .append("SELECT rgir FROM ResourceGroup rg JOIN
>> rg.implicitResources rgir WHERE rgir.inventoryStatus = 'COMMITTED'
>> AND
>> rg = "
>>                 + clusterKey.getClusterGroupId());
>>         } else {
>>             buildQuery(query, params, clusterKey, nodes.subList(0,
>>             size - 1));
>>         }
>>
>> We have a situation where the usage of implicitResources instead of
>> explicitResources appears to cause a performance issue. This occurs
>> for depth 3 resources related to the JVM (e.g. as JVM > Memory
>> Subsystem > MarkSweepCompact) in a compatible group. When trying to
>> open the summary for such a resource, the request times out because
>> the database takes too much time to complete the query. Note that
>> other resources at depth 3 are not affected by this problem. My guess
>> is that this is related to the fact that the keys of the resources in
>> the hierarchy ('JVM', 'java.lang:type=Memory' and
>> 'java.lang:name=MarkSweepCompact,type=GarbageCollector' in the
>> example) for these resources are "less unique" than for other
>> resources (we have 39 JVMs in the inventory).
>>
>> I tested the problematic database query, and if I replace
>> RHQ_RESOURCE_GROUP_RES_IMP_MAP by RHQ_RESOURCE_GROUP_RES_EXP_MAP,
>> then
>> it returns the same results, but much faster. Therefore I would like
>> to understand the meaning of the comment "this is an
>> authorization-related query, so use implicitResource (not
>> explicitResources)". Can somebody explain that to me?
>>
>> Andreas
>>
>> PS: I've investigated this with RHQ 4.5.1, but 3.0.0 had the same
>> problem.
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list