commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Haynes (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CONFIGURATION-425) FileChangedReloadingStrategy works differently on Unix and Windows
Date Mon, 15 Nov 2010 00:06:13 GMT

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

Dan Haynes commented on CONFIGURATION-425:
------------------------------------------

I did not have a chance to run the unit test you mentioned, but I did find a workaround for
the problem.

While I was trying to fix the code before, to be absolutely sure the file was being updated
I used FileUtils.forceDelete() on the destination file before doing the file copy. I had 
hoped that the Linux version would pick up on the file system change due to the delete. That
didn't work, it did not reload the properties file even though a 'cat' of the file showed
that it had indeed been completely replaced. 

In the source of the unit test you supplied I happened to notice that it uses file.delete()
while I'm  using FileUtils.forceDelete(). I changed my code to use FileUtils.deleteQuietly()
instead of FileUtilsforceDelete() and that makes the difference!

			File srcFile = new File(sourceFileName);
			File destFile = new File(destFileName);

			FileUtils.forceDelete(destFile);  <-- this doesn't work - the properties never gets
reloaded 
			FileUtils.deleteQuietly(destFile);  <-- this works, the properties file is reloaded
on the next access, as expected.
                        destFile.delete() <-- this doesn't work either, the properties
are never reloaded

			FileUtils.copyFile(srcFile, destFile, false);

I also tried it using destFile.delete(). Strangely enough, this also fails. Commons configuration
does not notice that the properties file has been modified (actually not just modified but
completely replaced)

I have try/catches for all possible exceptions, I see no exception thrown when using forceDelete()
or delete() - and technically speaking it doesn't seem like they should be needed since FileUtils.copyFile()
replaces the contents. Again, I verified that the properties file is updated by doing a 'cat'
on the file during the test and it shows the updated properties but for some reason commons
configuration never reloads the file. 

If I externally use 'cp' to copy a new properties file into place it does recognize the change
and reloads the properties as it should.

I'll see if I can find the time to build commons-configuration on the Linux box and run the
unit tests, but it may be a while. 

Thank you for your help!


> 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
>
> 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message