commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralph Goers (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CONFIGURATION-390) AbstractHierarchicalFileConfiguration is not thread safe
Date Sat, 26 Sep 2009 20:38:16 GMT

    [ https://issues.apache.org/jira/browse/CONFIGURATION-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759947#action_12759947
] 

Ralph Goers commented on CONFIGURATION-390:
-------------------------------------------

I don't understand the Accessor thing. The issue is that various operations have to be synchronized
since the underlying structure might change while the operation is being performed. I'm not
sure how this construct helps.

With CombinedConfiguration I also have focused on that bit of code and syncrhonized there
pretty much the way you have suggested but the use case I posted above still fails. From what
I can tell this is because in an XMLConfiguration the root node is cleared and then reloaded.
Apparently getTransformedRoot() adds the nodes from the actual HierarchicalConfiguration into
the CombinedConfiguration instead of making copies of them. This means that once the reloadLock
is released the CombinedConfiguration can be modified asynchronously.

The above shouldn't be a problem if it simply isn't allowed to use a Configuration object
directly once it is incorporated into a combined configuration.

> AbstractHierarchicalFileConfiguration is not thread safe
> --------------------------------------------------------
>
>                 Key: CONFIGURATION-390
>                 URL: https://issues.apache.org/jira/browse/CONFIGURATION-390
>             Project: Commons Configuration
>          Issue Type: Bug
>          Components: File reloading
>    Affects Versions: 1.6
>            Reporter: Emmanuel Bourg
>             Fix For: 1.7
>
>         Attachments: commons-configuration-390.patch, configtest.tar.gz, TestSuite.txt
>
>
> AbstractHierarchicalFileConfiguration doesn't implement the same locking mechanism found
in AbstractFileConfiguration. The consequence is that getting a property while the configuration
is being reloaded by another thread can return an invalid result.
> This can be demonstrated by changing testDeadlockWithReload() in TestCombinedConfiguration
to use an XMLConfiguration instead of a PropertiesConfiguration.
> Here is a reduced test case:
> {code:java}
> public void testConcurrentGetAndReload() throws Exception
> {
>     //final FileConfiguration config = new PropertiesConfiguration("test.properties");
>     final FileConfiguration config = new XMLConfiguration("test.xml");
>     config.setReloadingStrategy(new FileAlwaysReloadingStrategy());
>     assertTrue("Property not found", config.getProperty("test.short") != null);
>     new Thread()
>     {
>         public void run()
>         {
>             for (int i = 0; i < 1000; i++)
>             {
>                 config.reload();
>             }
>         }
>     }.start();
>     
>     for (int i = 0; i < 1000; i++)
>     {
>         assertTrue("Property not found", config.getProperty("test.short") != null); //
failure here
>     }
> }
> {code}
> The test doesn't always fail. It does about 50% of the time.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message