commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Heger (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CONFIGURATION-425) FileChangedReloadingStrategy works differently on Unix and Windows
Date Fri, 29 Oct 2010 19:36:20 GMT

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

Oliver Heger updated CONFIGURATION-425:
---------------------------------------

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



  was:
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:

		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");
		}

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.




> 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