You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Oliver Heger (JIRA)" <ji...@apache.org> on 2008/11/05 22:07:44 UTC
[jira] Created: (CONFIGURATION-347) Iterating over the keys of a
file-based configuration can cause a ConcurrentModificationException
Iterating over the keys of a file-based configuration can cause a ConcurrentModificationException
-------------------------------------------------------------------------------------------------
Key: CONFIGURATION-347
URL: https://issues.apache.org/jira/browse/CONFIGURATION-347
Project: Commons Configuration
Issue Type: Bug
Components: File reloading
Affects Versions: 1.5
Reporter: Oliver Heger
Some implementations of FileConfiguration return an iterator in their {{getKeys()}} method that is directly connected to the underlying data store. When now a reload is performed (which can happen at any time) the data store is modified, and the iterator becomes invalid.
This behavior is very confusing because ConcurrentModificationExceptions are typically related to multi-threading access. But even if the code performing the iteration is the only instance that accesses the configuration, the exception can be thrown.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CONFIGURATION-347) Iterating over the keys of a
file-based configuration can cause a ConcurrentModificationException
Posted by "Oliver Heger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oliver Heger resolved CONFIGURATION-347.
----------------------------------------
Resolution: Fixed
Fix Version/s: 1.6
AbstractFileConfiguration.getKeys() now creates a snapshot of the keys contained in the configuration when the method is called. Then an iterator of this snapshot is returned. This avoids ConcurrentModificationExceptions.
Clients should be aware that changes made at the configuration (including those caused by reload operations) are not reflected by the iterator. The Javadocs of AbstractFileConfiguration.getKeys() has been updated correspondingly.
> Iterating over the keys of a file-based configuration can cause a ConcurrentModificationException
> -------------------------------------------------------------------------------------------------
>
> Key: CONFIGURATION-347
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-347
> Project: Commons Configuration
> Issue Type: Bug
> Components: File reloading
> Affects Versions: 1.5
> Reporter: Oliver Heger
> Fix For: 1.6
>
>
> Some implementations of FileConfiguration return an iterator in their {{getKeys()}} method that is directly connected to the underlying data store. When now a reload is performed (which can happen at any time) the data store is modified, and the iterator becomes invalid.
> This behavior is very confusing because ConcurrentModificationExceptions are typically related to multi-threading access. But even if the code performing the iteration is the only instance that accesses the configuration, the exception can be thrown.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.