Auto refreshing properties from property files

I have written a tool to automatically reload a property file on file change. This tool came very handy when implementing stand alone server applications that cannot resort to a server restart for refreshing properties. The class itself is a simple construct that spawns a LOW_PRIORITY thread to monitor the property file and reload the properties when the file has changed. To address some specific use cases where the system should be notified of such a reloading of properties I have also provided a mechanism to add listeners. In the following sample snippet an instance of AutoRefreshingProperties is instantiated against ‘config/configuration.properties’. We are also adding two listeners who are interested to know of any file changes.

To test whether the gig really works we are then changing the contents of the properties file by copying over another properties file to the same location. From my experience I can relate to this test case very well since there are dozens of instances where restarting a running server is not an option to change a simple property.

The source code that did this auto loading is not very complex either. It extends the java.util.Properties and adds a new constructor that accepts an absolute file path as the location of the property file that needs auto loading. This suffices the problem I am trying to solve since it is highly unlikely that one needs to change a property file embedded in a jar file. More often than not a fix folder (say ‘config’) houses the configuration files and this folder is added to the classpath.

In the simplest of usage scenarios all you will need to do the auto loading feature is to just create an instance of AutoRefreshingProperties by passing the path to the properties file. The class will take care of monitoring the file and reloading itself on file change. So at any point of tile when the system makes a call to Properties.getProperty(…) it will return the latest value specified in the properties file. As I have shown in the test case the power of this tool can be extended by attaching listeners and taking appropriate reactive actions on property changes.

The feature that I would love to see augmented to such a solution is how a spring bean property configured through PropertyPlaceholderConfigurer can load an refresh the beans on property file changes. In my opinion that solution will not be as trivial as the one I cooked up here. Having said that one can very easily use the notification listener mechanism to do whatever it needs to do on such an event.

JDK7 has a WatchService specificatiion. The b64 release has this interface in place. Such a support from JVM will alleviate a lot of thread management issues that each of us have cooked up for file and directory monitoring.

15 Thoughts on “Auto refreshing properties from property files”

This would not be good in a JEE environment where you are not supposed to manage your own threads.

Also, it’s silly to create a single thread executor and pass it threads. First, you can just pass runnables to executors. Second, you’re only ever passing one runnable to the executor. You should just replace that code with

new Thread() { .. }.start();

Look at how Apache commons-configuration does it with their FileChangedReloadingStrategy. Maybe you could just use commons-configuration in your applications when you need this functionality.

You should also test to see if removing properties from your file results in the property being removed from the AutoRefreshingProperties object.

Using a thread ExecutorService comes out of habit. I know from a lot of concurrency solution experience that the Executor Service managed threads are much better behaved. Esepecially in this scenario where it is watching a file.

Which JEE environment do you feel might pose a problem? Most of the JEE app servers provide a mechanism to use a TimerTask kind of construct. I am pretty sure that piggybacking on such mechanism will let us use this class and then a listener to update the properties to the JNDI tree. Do you see any specific challenges in this approach? I agree that spawning this class in an Ejb instance will not be very appropriate because of the lifecycle controls the container has to do and a hanging thread will mess with the life cycle management.

Using Runnable in place of Thread : I think in general it is a good idea because we can take away some memory over heads. Since Thread is a runnable the currentl implementation is not a bad code though. I think I must have used thread just because I was lazy to create a new Impl

Thanks for pointing out the Apache commons configuration. I just hate reinventing a wheel. Looks like I just did one. My bad!!

And finally, since the monitor is a dumb thread that watches for file changes through modification date it works (tested too) when properties are removed from the file.

1. The ‘synchronize’ keyword does nothing on the thread for the following reason:

synchronized in the ‘run’ will lock the object itself (which is the anonymous Thread object), nobody else try to get the thread monitor for that object. (thus the public load() method can be executed paralelly.) I suppose you put the synchronized keyword there for this reason. Looping forever in a synchronized section is somewhat unusual.

2. In the watch thread you loop forever. You should at least add a Thread.yield() or even better some sleep(). Even if it is low prio, it can consume lots of cpu power. And who cares if you reload after 2-300ms only.

Actually you need to synchronize access to any of the properties methods when you’re updating the properties object since its not inherently synchronized. I think the lazy reload approach taken by the Apache folks is better if you’re in a development environment whereas your approach is more pro-active and makes more sense in a production environment (why make the caller wait for the properties to be reloaded).

You should consider implementing a locking mechanism to prevent concurrent access to the properties object. You might want to consider implementing a Proxy to the underlying Properties object.