"
Using Terracotta for Configuration Management" by JR Boyens details using Terracotta to propagate configuration management on the fly across a network, such that a client can pull up its configuration data live. Terracotta suggests that this is an excellent use of the platform; while this article is cursory, the concept is valid.
Configuration management, for lack of a better term, is a serious problem for a lot of growing businesses. Having only one server and, therefore, one configuration is not really something that requires a lot of management. Once you start to get past 5 – 10 servers with different configurations for each one, it gets to be a little much. Continue on and very quickly configuration gets to be a real problem. Making sure that the right host/app runs the right configuration at the right time in a dynamic environments is tricky at best. After evaluating numerous possible solutions we have finally settled on using Terracotta. We can easily share object graphs for managing our configurations across all of our servers. This simplifies having each node running many different applications with unique configurations. The purpose of this article is to let you know about our issues, what we initially thought of doing, what we ultimately decided upon, and how we implemented it.
Terracotta, if you're not familiar, is a sort of network shared memory system. It shares object graphs across the cluster, through something called a "shared root." You declare a Java field as a shared root and then Terracotta handles updating all the nodes in the "cluster" with the information as it changes. It avoids excessive overhead by only sending deltas to keep the objects in sync. The Terracotta folks do a great job explaining their technology in their Introduction to Terracotta - and you can see the object graph being declared as a shared root in the configuration later in this article.
Speaking of what this article is about: basically, the Java Properties system is based on maps. You feed the Properties object a key, and get a value out. What we needed to be able to do is specify a "global properties" object that would allow us to update the properties after the application had been deployed, and alter values based on hostnames and server roles.
