Issues With Publishing ECE JMX Changes to Charging-settings.xml (Doc ID 2456578.1)

Last updated on SEPTEMBER 19, 2023

Applies to:

Symptoms

On Oracle Communications Elastic Charging Engine (ECE), 11.3.0.6.0 version,

Scenario A:
Double "republishAllAppConfigurationAttributes" from JConsole causes corruption of charging-settings.xml.

If one clicks on the ECE Configuration: System Admin JMX "republishAllAppConfiguration" buttons multiple times in a short period, it will corrupt the application configuration files under ECE_HOME/config/management.  The ECE server logs show the below exception and error messages related to the corrupted configuration files.

ecs.log:

STEPS:
The issue can be reproduced at will with the following steps:

1. Make a backup of *all* xml files (including charing-settings.xml) from $ECE_SERVER_HOME/config/management.
2. Open JConsole and connect to ECS JMX management console.
3. Navigate to ECE Configurations -> systemAdmin -> Operations and trigger (press) "republishAllAppConfigurationAttributes"
4. Wait 1-2 seconds and AGAIN trigger "republishAllAppConfigurationAttributes"

Actual Behavior:
5. Eventually, 'two' popup windows appears and the charging-settings.xml is corrupted (wrong size, wrong content, etc).
6. The only way to restore is to revert config/management/charging-settings.xml from a backup and delete $ECE_SERVER_HOME/tmp/charging-settings.xml. Otherwise publishing will always fail

Questions:

• Why $ECE_SERVER_HOME/tmp/charging-settings.xml is getting promoted to config/management/charging-settings.xml despite it is corrupted? Isn't the whole idea of temporary file to protect the main file in case of issues?
• What is the publishing mechanism and why ECS keeps re-writing to charging-settins.xml a few times (even when just a single publishing is triggered)?

Expected Behavior:

• A control mechanism to either queue republishing requests or a lock mechanism is needed.
• Error message in JConsole in case of publishing failure. Currently the message says "Method successfully invoked", regardless if it was successful or not.

Scenario B:
The "republishAllAppConfigurationAttributes" from JConsole does not update the XML in the secondary (hot-standby) site.

At the end of republishing, it is observed that the config files in Site2 are not updated. It may be possible that this file is not updated as there are no changes in the MBeans (and the file), however, for test purposes, the user have slightly updated the Site2 xml as well. So, one can see that after end of the republishing, the sizes still does not match and only after setting an other MBean, this is published to both sites.

Expected Behavior:

• Operation "republishAllAppConfigurationAttributes" republishes xmls in all the sites.

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.