Bug 735810 - SystemManagerRemote.setSystemConfiguration can invalidate the internal cache of system settings
SystemManagerRemote.setSystemConfiguration can invalidate the internal cache ...
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Core Server (Show other bugs)
4.1
Unspecified Unspecified
high Severity high (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
:
Depends On:
Blocks: jon30-bugs
  Show dependency treegraph
 
Reported: 2011-09-05 10:25 EDT by Lukas Krejci
Modified: 2012-02-07 14:27 EST (History)
2 users (show)

See Also:
Fixed In Version: 4.2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-07 14:27:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Lukas Krejci 2011-09-05 10:25:17 EDT
Description of problem:
SystemManagerRemote.setSystemConfiguration() method assumes that the Properties passed to it contain a superset of all the properties that are already defined in the database (i.e. it correctly handles the scenarios where the properties passed to it contain the same names or contain the same names and some new ones).

The cached properties that are then used in other places in the code are assigned to a copy of properties passed to this method. This results in the fact that the properties that are in the database but weren't in the passed in properties suddenly seem to have disappeared even though they are still present in the database.

This condition is intermittent because the system config cache is being reloaded every minute but still opens a window where the business layer reports inconsistent data.

Because setSystemConfiguration() is a remote method we should make it as robust as possible.

How reproducible:
always

Steps to Reproduce:
1.Using the CLI, log in as a user having at least MANAGE_SETTINGS privs:
var props = SystemManager.systemConfiguration;
pretty.print(props.get("CAM_BASE_URL");//prints out the URL of the server
props.remove("CAM_BASE_URL");
SystemManager.setSystemConfiguration(props, false);
props = SystemManager.systemConfiguration;
pretty.print(props.get("CAM_BASE_URL"); //prints nothing
//.... wait a couple of minutes
props = SystemManager.systemConfiguration;
pretty.print(props.get("CAM_BASE_URL"); //prints the URL again
  
Actual results:
see steps

Expected results:
no inconsistency in the reported properties

Additional info:
Comment 1 Lukas Krejci 2011-09-27 17:22:21 EDT
commit 72430377515c26d205d7664485fcb69d19db14e4
Author: Lukas Krejci <lkrejci@redhat.com>
Date:   Fri Sep 9 16:25:55 2011 +0200

    BZ-735810 - make sure to reload the system config cache after its update.
Comment 2 Sunil Kondkar 2011-09-30 07:11:18 EDT
Verified on build#449 (Version: 4.1.0-SNAPSHOT Build Number: 4d56f0b)

Created a user and assigned MANAGE_SETTINGS privileges to the user. Logged in to the CLI with the user.
Below are the steps followed.

var props = SystemManager.systemConfiguration;
pretty.print(props.get("CAM_BASE_URL"));       //prints out the URL of the server
props.remove("CAM_BASE_URL");
SystemManager.setSystemConfiguration(props, false);
props = SystemManager.systemConfiguration;
pretty.print(props.get("CAM_BASE_URL"));       //prints the URL of the server
//.... wait a couple of minutes
props = SystemManager.systemConfiguration;
pretty.print(props.get("CAM_BASE_URL"));       //prints the URL again
Comment 3 Mike Foley 2012-02-07 14:27:37 EST
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE

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