Bug 829944

Summary: [cli] Inconsistent caching of resource proxy types
Product: [Other] RHQ Project Reporter: Lukas Krejci <lkrejci>
Component: Alerts, CLIAssignee: RHQ Project Maintainer <rhq-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: hrupp
Target Milestone: ---   
Target Release: RHQ 4.5.0   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-01 06:11:34 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 801638, 1011224    

Description Lukas Krejci 2012-06-07 16:38:11 EDT
Description of problem:
The CLI generates a custom java type on the fly for each of the resource types it encounters. It caches these types based on the resource type structure based on which it creates a "fingerprint" of a type.

The creation of this fingerprint is sensitive to the order of definitions in the type (measurement defs, operations, package types, property defs in the plugin and resource configuration definitions). Because the order of some of these structures is not guaranteed when retrieved from the server, it could happen that 1 resource type could have 2 different fingerprints.

The caching algorithm assumes that there is exactly 1 fingerprint for a type and that if there has been a change in the resource type structure, then the resource type must have been updated on the serverside (by plugin update).

The following scenario would give rise to errors in the CLI with resource proxies NOT containing the expected methods and properties:

1) Fingerprint f1 generated for a resource type, the custom type cached
2) Fingerprint f2 generated for a resource type, another custom type cached
3) During request for another resource proxy, the fingerprint f1 is generated again, but because the cache contains the custom type as generated for f2, the cache assumes f1 is "new" and tries to create a new custom type. This fails because the custom type for f1 has already been created with a name that is based on the fingerprint.
4) The proxy is created with from a "raw" ResourceClientProxy missing any of the methods or properties that get dynamically generated based on the resource type structure.

For some reason that is not entirely clear to me, this happens most frequently when running operations on a resource. The reason might be that running an operation on resource add operation history entries which *might* in some way modify the order of operation definitions returned from the database (because we don't define any order on the results).

Version-Release number of selected component (if applicable):

How reproducible:
frequently, but not always

Steps to Reproduce:
1. Pick a resource with some operations on it (i used AS7 standalone with the restart() operation).
2. Run the following script on the CLI command line (copy it as a one line if directly pasting it):

for (i = 0; i < 10; i++) {
    var r = ProxyFactory.getResource(10264); 
    if (!r.pluginConfiguration) {

(change 10264 to the actual resource id and r.restart() to an operation you pick)
Actual results:
On *some* occassions the above will output "BOOM".

Expected results:
no booms

Additional info:
Comment 1 Lukas Krejci 2012-06-07 16:51:44 EDT
note that this affects both CLI proper and server-side alert scripts
Comment 4 Lukas Krejci 2012-06-08 06:52:48 EDT
master http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commitdiff;h=a48f5cda6610222c37b42fb80d29fa589a864ab5
Author: Lukas Krejci <lkrejci@redhat.com>
Date:   Fri Jun 8 12:51:28 2012 +0200

    [BZ 829944] - make the resource type fingerprint robust against ordering
    of different kinds of definitions in the resource type.
Comment 5 Heiko W. Rupp 2013-09-01 06:11:34 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.