ARTEMIS-5871 restrict reload of properties config to the set of reloa… #6205
Conversation
|
There is a use case where a user has a coded configuration impl that they pass to the broker, if that contains re loadable config and there are the same entries in a properties file that is reloaded, then the reload will take precedence. In this case there are two sources of truth and one is re-loadable, I think this is the expected behaviour, but due to this bug, it is not currently the case. |
...mis-server/src/main/java/org/apache/activemq/artemis/core/config/impl/ConfigurationImpl.java
Outdated
Show resolved
Hide resolved
It wont just 'take precedence', it could silently toss original configuration even where they dont overlap at all, giving potentially a completely different result than when the very same properties were applied at startup. So even touching the file could alter config vs startup, which itself seems like an issue. FWIW, you added a startup class for use with images thats specifically using that behaviour, and added ability to change the properties path on another related embedding class that then allows it too, so youll likely need to look at updating those, and some of the tests that use it, if you want to change this. |
…dable config elements
|
configurationFileRefreshPeriod=-1 is necessary if there are multiple source of truth for config that supports reload. |
|
@gemmellr I peeked at the image example tests, none have overlapping re-loadable config. I cannot find any broken usage in our test suite. |
| } | ||
|
|
||
| @Override | ||
| public Configuration setJaasConfigs(Map<String, JaasAppConfiguration> configs) { |
There was a problem hiding this comment.
I would normally expect a set method like this to clear the old values before writing the provided new set of entries, this one is just confuses me and seems to run counter to anything I'd expect a set method to do. The other set methods here just replace the old collection with the new one, why it this one different?
| configuration.parseProperties(propertiesFileUrl); | ||
| config.parseProperties(propertiesFileUrl); | ||
| configuration.setStatus(config.getStatus()); | ||
|
|
There was a problem hiding this comment.
This seems to disregard any configuration that was assigned programmatically via an initial configuration object when it sets the configuration from the reload of the possible XML file and then the properties file. It creates an empty configuration vessel which it might fill in from XML and or a properties file(s) set and then hard sets those entries into the existing configuration regardless of the differences between old and new which could lose original data. Its not clear when or why these differing configuration sets take precedence over each other.
3 participants
…dable config elements