Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <1241032855.1253979436001.JavaMail.jira@brutus>
Date: Sat, 26 Sep 2009 08:37:16 -0700 (PDT)
From: "Oliver Heger (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Updated: (CONFIGURATION-390)
 AbstractHierarchicalFileConfiguration is not thread safe
In-Reply-To: <1526663720.1245772207345.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CONFIGURATION-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oliver Heger updated CONFIGURATION-390:
---------------------------------------

    Attachment: commons-configuration-390.patch

I have created a unit test that fails more reliably and a proposed fix.

The idea is that the lock used by the {{reload()}} method is exposed so that external synchronization can be performed. {{AbstractHierarchicalFileConfiguration}} now synchronizes at this lock in its {{getProperty()}} method. This does not fix all problems with this architecture, e.g. other methods like {{isEmpty()}} or {{containsKey()}} should be treated in a similar way. But concurrent property reads should now be possible.

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