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 2016/03/24 21:13:26 UTC
[jira] [Updated] (CONFIGURATION-425) FileChangedReloadingStrategy
works differently on Unix and Windows
[ https://issues.apache.org/jira/browse/CONFIGURATION-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oliver Heger updated CONFIGURATION-425:
---------------------------------------
Fix Version/s: (was: 2.0)
2.x
> FileChangedReloadingStrategy works differently on Unix and Windows
> ------------------------------------------------------------------
>
> Key: CONFIGURATION-425
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-425
> Project: Commons Configuration
> Issue Type: Bug
> Components: File reloading
> Affects Versions: 1.6
> Environment: Windows 7 x64 and Ubuntu 10.04 Server
> Reporter: Dan Haynes
> Priority: Minor
> Fix For: 2.x
>
>
> I created a unit test for a configuration class that uses commons configuration. It loads both a set of static properties and a set of dynamic properties, the latter uses FilechangeReloadingStragegy. The unit test copies a file containing an initial set of of dynamic properties (using commons-io FileUtils.copy()) , verifies the values are as expected and then copies an updated set of properties, sleeps longer than the refresh delay and then verifies the new values are in place.
> On WIndows it works as expected. It recognizes that FileUtils.copy() has replaced the dynamic.properties file with an updated version and it loads the new property values.
> On Linux, nothing I do makes it recognize that the file has been replaced except by actually opening a shell and editing the dynamic.properties values. Then it works as expected.
> This may well be my lack of understanding of some Unix filesystem behavior but it seems like FilechangeReloadingStrategy should notice the change to the file one way or the other.
> The unit test looks like so:
> {code}
> final ConfigurationManager cm = new StandardConfigurationManager(staticTestPropertiesFileName, dynamicTestPropertiesFileName);
> /*
> * Initialize the configuration manager. This should read all the initial values.
> */
> cm.init();
> Assert.assertEquals(System.getProperty("java.user"), cm.retrieveUserName());
> /*
> * Verify that the static properties were read.
> */
> Assert.assertEquals("1.00", cm.retrieveVersionId());
> /*
> * Verify that the initial values for the dynamic properties were read.
> */
> Assert.assertEquals(100, cm.retrieveMaxConcurrentLogons());
> if (copyFile(updatedConfigFileName, dynamicTestPropertiesFileName))
> {
> /*
> * The default update window for Apache commons configuration file reload strategy is 5 seconds
> * so wait more than 5 seconds to ensure the new value will be read.
> */
> log.info("Sleeping until configuration refresh delay has passed");
> sleep(6000L);
> log.info("Woke, resuming test, maxConcurrentLogons = " + cm.retrieveMaxConcurrentLogons());
>
> /*
> * Verify that the property was updated to the expected new value.
> */
> >>> this fails every time on Linux: Assert.assertEquals(1, cm.retrieveMaxConcurrentLogons());
> }
> else
> {
> Assert.fail("Couldn't copy updated test properties file");
> }
> {code}
> I've tried everything I could think of to trigger the reload strategy. After calling FileUtils.copy() on the file I added a FileUtils.touch() on the destination file. That didn't work so I added a "Process process = runtime.exec("touch " + destFile.getAbsolutePath());" to be absolutely 100% certain the file timestamp is being updated. It gets updated, but the reloading strategy never recognizes it.
> I googled and searched the JIRA incidents and the only thing I can find that looks similar are some references to a problem in V1.1 that was fixed long ago.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)