Issues With Publishing ECE JMX Changes To Charging-settings.xml
(Doc ID 2456578.1)
Last updated on JANUARY 04, 2021
Applies to:Oracle Communications BRM - Elastic Charging Engine - Version 126.96.36.199.0 and later
Information in this document applies to any platform.
On Oracle Communications Elastic Charging Engine(ECE), 188.8.131.52.0 version,
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 is observed that it will corrupt the application configuration files under ECE_HOME/config/management. The ECE server logs shows the below exception and error messages related to the corrupted app configuration files.
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"
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
- What is publishing mechanism and why the ECS keeps re-writing to charging-settins.xml a few times (even when just a single publishing is triggered)? File changes it's size and whole process seems repeated multiple times.
- 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?
- 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.
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.
- Operation "republishAllAppConfigurationAttributes" republishes xmls in all the sites.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document