commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Heger (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CONFIGURATION-530) AbstractFileConfiguration.getProperty(String key) locking causes thread hault
Date Wed, 13 Mar 2013 20:58:13 GMT

    [ 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

Mime
View raw message