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

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

Oliver, I have created a very similar patch but I am using the reloading lock 
on a lot more methods such as containsKey(), etc. This is necessary because all 
these methods are at risk of having the underlying structure change, not just 
getProperty.

However, CombinedConfiguration seems to be a tougher nut to crack. The test I 
am using is below and is a variation on the XMLConfiguration test case and was 
added to TestCombinedConfiguration and fails every time.
    public void testConcurrentGetAndReload() throws Exception
    {
        config.setForceReloadCheck(true);
        config.setNodeCombiner(new MergeCombiner());
        //final FileConfiguration config = new 
PropertiesConfiguration("test.properties");
        final XMLConfiguration xml = new XMLConfiguration("test.xml");
        xml.setReloadingStrategy(new FileAlwaysReloadingStrategy());
        config.addConfiguration(xml);

        assertTrue("Property not found", config.getProperty("test.short") != 
null);

        Thread testThreads[] = new Thread[5];

        for (int i = 0; i < testThreads.length; ++i)
        {
            testThreads[i] = new ReloadThread(xml);
            testThreads[i].start();
        }

        for (int i = 0; i < 2000; i++)
        {
            assertTrue("Property not found", config.getProperty("test.short") 
!= null);
        }

        for (int i = 0; i < testThreads.length; ++i)
        {
            testThreads[i].join();
        }
    }

    private class ReloadThread extends Thread
    {
        FileConfiguration config;

        ReloadThread(FileConfiguration config)
        {
            this.config = config;
        }
        public void run()
        {
            for (int i = 0; i < 1000; i++)
            {
                config.reload();
            }
        }
    }

> 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.

Reply via email to