[
https://issues.apache.org/jira/browse/CONFIGURATION-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-570.
----------------------------------------
Resolution: Fixed
Fix Version/s: 2.0
Fixed in SVN in revision 1623863.
The {{getKeys()}} implementation in {{SystemConfiguration}} was changed to
return a snapshot of the keys currently stored in the system properties. Thus
{{ConcurrentModificationExceptions}} can no longer occur.
> Passing SystemConfiguration() into PropertiesConfiguration() can cause a
> ConcurrentModificationException
> --------------------------------------------------------------------------------------------------------
>
> Key: CONFIGURATION-570
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-570
> Project: Commons Configuration
> Issue Type: Bug
> Affects Versions: 1.6
> Reporter: John Vines
> Fix For: 2.0
>
>
> This was encountered in a release of Accumulo. I'm not sure if this is in the
> realm of commons configuration, but I figured I should put in a ticket-
> A. just in case it is or
> B. So others can be aware of this issue
> We had a piece of code which interpolates java properties
> (SystemConfiguration) with other variables. This code worked as follows
> {code}
> PropertiesConfiguration pconf = new PropertiesConfiguration();
> pconf.append(new SystemConfiguration());
> pconf.addProperty("hack_default_value", this.defaultValue);
> String v = pconf.getString("hack_default_value");
> {code}
> However, after we added a monitor thread which calls System.setProperty
> before this code is hit, we would occasionally get a
> ConcurrentModificationException.
> I traced it down to pconf.append doing an iteration over the Configuration
> (AbstractConfiguration, line 1233 in 1.6). The configuration being passed in,
> SystemConfiguration, is just a MapConfiguration from the result of
> System.getProperties. This is an exact copy of the map the System maintains.
> There are two accessors to that map, setProperty and setProperties in System.
> Set property basically just falls to Properties.setProperty, while
> setProperties will copy the existing properties, add new ones, and then
> replace the object. We are using setProperty in our code.
> Properties.setProperty is a synchronized call, so we resolved it by replacing
> our code with
> {code}
> PropertiesConfiguration pconf = new PropertiesConfiguration();
> Properties systemProperties = System.getProperties();
> synchronized (systemProperties) {
> pconf.append(new MapConfiguration(systemProperties));
> }
> pconf.addProperty("hack_default_value", this.defaultValue);
> String v = pconf.getString("hack_default_value");
> {code}
> I'm not quite sure if/how it should be handled in commons configuration. I'm
> thinking if it IS in the scope of this project, then SystemConfiguration
> should create a snapshot of System.getProperties. Or a new
> Configuration/configuration flag should be added to create a snapshot of it
> instead of the map directly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
