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 2013/03/13 21:58:13 UTC
[jira] [Commented] (CONFIGURATION-530)
AbstractFileConfiguration.getProperty(String key) locking causes thread
hault
[ https://issues.apache.org/jira/browse/CONFIGURATION-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601626#comment-13601626 ]
Oliver Heger commented on CONFIGURATION-530:
--------------------------------------------
Currently, work on a redesigned version 2.0 is going on. This also includes reworking file-based configurations and improved support for concurrent access. There is already code in subversion showing the direction I would like to go. The basic ideas are as follows:
* Configurations are now created by builder objects.
* Reloading is moved from configurations to builders. This means, the content of a configuration will not change due to a reload while you work with it. Only if you query the builder again, it might return another configuration instance if a reload was performed in the meantime. So there is no need to synchronize because of possible reloads.
* It is planed to rework the concept of concurrent access to configuration objects. The idea is to use a similar concept as for Java collection classes: Plain configurations are not thread-safe, but it should be possible to create synchronized configurations if required.
> AbstractFileConfiguration.getProperty(String key) locking causes thread hault
> -----------------------------------------------------------------------------
>
> Key: CONFIGURATION-530
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-530
> Project: Commons Configuration
> Issue Type: Bug
> Components: File reloading
> Affects Versions: 1.9
> Reporter: yair ogen
> Priority: Critical
>
> Every call to getProperty causes a lock (related to the reload functionality). In a near real-time system where we have many concurrent threads this affects heavily on the application TPS.
> Possible solution will be: getProperty only returns current value. Reload when needed occurs in a background thread that updates the in-memory map (perhaps by using CopyOnWrite collections?).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira