Bug 591271 - configuration objects not properly cleaned up
configuration objects not properly cleaned up
Status: CLOSED WONTFIX
Product: RHQ Project
Classification: Other
Component: Configuration (Show other bugs)
3.0.0
All Linux
medium Severity medium (vote)
: ---
: ---
Assigned To: Charles Crouch
Mike Foley
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-11 15:08 EDT by Joseph Marques
Modified: 2015-02-01 18:26 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-05-29 14:02:27 EDT
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 Joseph Marques 2010-05-11 15:08:40 EDT
Description of problem:

ConfigurationManagerBean.deleteConfigurations(List<Integer> configIds) is not coded properly.

It executes "Configuration.QUERY_DELETE_PROPERTIES_BY_CONFIGURATION_IDS" query twice, which was a copy/paste error introduced in Dec 2008 as part of the fix for https://bugzilla.redhat.com/show_bug.cgi?id=RHQ-1260

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

1.2.0 -> 1.3.1

How reproducible:

Every time

Steps to Reproduce:
1a. Go to /admin/test/hibernate.jsp
1b. Execute "select count(c) from Configuration c", record the count
1c. Execute "select count(p) from Property p", record the count
2. Execute an operation (on any resource) that has either arguments, or results, or both
3. Wait until the operation completes
4. Delete the corresponding operation history entry
5. Repeat the steps in 1a/1b/1c, and records both counts again
  
Actual results:

The second set of counts is higher, indicating that the configuration/property objects are not being properly expunged.

Expected results:

The configuration counts should be the same before and after the operation execution and deletion of the audit trail record.  The property counts should be the same before and after the operation execution and deletion of the audit trail record.
Comment 1 Joseph Marques 2010-05-12 17:05:05 EDT
commit aca1ebad9820103bea6617fc2daee810e315b9c6

fix broken ConfigurationManagerBean.deleteConfigurations(List<Integer> configIds) method:
    
* no longer need to explicitly delete properties, they are cascade deleted at the DB-level
* fix typo to change configurationsQuery to use Configuration.QUERY_DELETE_CONFIGURATIONS_BY_CONFIGURATION_IDS
* add new query to break property recursion for DBs that don't support self-referencing cascading
** this means that nested (non-top-level) properties will be orphaned on MSSQL, which doesn't support that recursive cascade
* finally, needed to clean out RawConfiguration objects along with the delete
Comment 2 Corey Welton 2010-06-08 12:23:14 EDT
Returning this one to dev.  I don't think configuration and property counts are giving us the right results.



run #1 - recent hudson build, reasonably heavy inventory, postgres
======
* executed 'select count(c) from Configuration c' =  3937
* executed 'select count(p) from Property p' =  46267
* ran autodiscovery op with "yes" as the detailed results parameter.
* deleted op history
* executed 'select count(c) from Configuration c' =  3938
* select 'count(p) from Property p' =  46268


run #2 - proposed beta build, light inventory, postgres
======
2475
20567
platform: autodiscovery / yes
deleted op
2476
20568

run #3 - same config as above, but deleted all op history prior to run.
======
2474
20566
platform: audodiscovery / yes
deleted op history
2475
20567

run #4 - same config as run #3; performing different op w/ param
======
2475
20567
apache: install mod_jk configuration with "Yes" as the parameter
deleted op
2476
20568
Comment 7 Jay Shaughnessy 2014-05-29 14:02:27 EDT
It's known that not all Config entries get cleaned up.  The work to do complete cleaning is too high.

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