In a cluster production environment there is a lot of tuning involved and as different servers are involved in the process so it becomes really difficult to set the tc-properties at each machine. In 2.7 release of the Terracotta product this issue has been addressed and now it has become really easy to tune the cluster.
Before explaining the new feature lets have a look how the tuning is being done at each server before 2.7 release. Terracotta cluster has a lot of tuning paramerters called tc-properties which a user can set for different servers involved in the cluster. The installation comes with full set of default values for these parameters. To tune the application for a specific environment these properties need to be overwritten. We can overwrite the default tc-properties by creating a file tc.properties and specifying the path while running the server. One other way to overwrite these parameters by adding them to the jvm arguments of the application like "-Dcom.tc.l1.transactionmanager.logging.enabled=true"
The order in which these properties are overwritten is as below
1. Default tc-properties (comes in the installation)
2. Local tc.properties file
3. System properties
The new feature is aimed at giving the user flexibility to set some parameters using tc-config file and as generally in production environment tc-config is kept at one server(L2) and all other nodes(l1) take their config from it so it gives the user a flexibility to set the parameters at one place and getting it reflected at all the nodes.
USAGE
To get the advantage of this feature all you need to do is to add one more section in the tc-config file and you are done. The format of the section is as below
1. Default tc-properties (comes in the installation)
2. Property from the tc-config file
3. Local tc.properties file
4. System properties
Note that we still give precedence to local tc.properties file and system properties. This is because we still want to give the user the option to tune the cluster by setting the properties for individual server. Whenever any property is overwritten by the tc-config file a log entry is added, similarly when any property can not be overwritten because we have set them in local tc.properties or in system properties a warning is added in the logs mentioning the failure of the overwriting by tc-config file.
P.S: You can give tc properties file path while starting the server/clients by adding "-Dcom.tc.properties=<pathToTcPropertiesFile>"
This feature can be a very useful tool for the cluster tuning and i hope people will enjoy using it and i hope this blog can give you help in the same.
Have fun guys!!
Before explaining the new feature lets have a look how the tuning is being done at each server before 2.7 release. Terracotta cluster has a lot of tuning paramerters called tc-properties which a user can set for different servers involved in the cluster. The installation comes with full set of default values for these parameters. To tune the application for a specific environment these properties need to be overwritten. We can overwrite the default tc-properties by creating a file tc.properties and specifying the path while running the server. One other way to overwrite these parameters by adding them to the jvm arguments of the application like "-Dcom.tc.l1.transactionmanager.logging.enabled=true"
The order in which these properties are overwritten is as below
1. Default tc-properties (comes in the installation)
2. Local tc.properties file
3. System properties
The new feature is aimed at giving the user flexibility to set some parameters using tc-config file and as generally in production environment tc-config is kept at one server(L2) and all other nodes(l1) take their config from it so it gives the user a flexibility to set the parameters at one place and getting it reflected at all the nodes.
USAGE
To get the advantage of this feature all you need to do is to add one more section in the tc-config file and you are done. The format of the section is as below
<tc-properties>
<property name="l1.cachemanager.enabled" value="true"/>
<property name="logging.maxLogFileSize" value="1024"/>
<property name="l1.cachemanager.leastCount" value="9000"/>
</tc-properties>
The order in which the tc-properties are overwritten now from 2.7 release is as below<property name="l1.cachemanager.enabled" value="true"/>
<property name="logging.maxLogFileSize" value="1024"/>
<property name="l1.cachemanager.leastCount" value="9000"/>
</tc-properties>
1. Default tc-properties (comes in the installation)
2. Property from the tc-config file
3. Local tc.properties file
4. System properties
Note that we still give precedence to local tc.properties file and system properties. This is because we still want to give the user the option to tune the cluster by setting the properties for individual server. Whenever any property is overwritten by the tc-config file a log entry is added, similarly when any property can not be overwritten because we have set them in local tc.properties or in system properties a warning is added in the logs mentioning the failure of the overwriting by tc-config file.
P.S: You can give tc properties file path while starting the server/clients by adding "-Dcom.tc.properties=<pathToTcPropertiesFile>"
This feature can be a very useful tool for the cluster tuning and i hope people will enjoy using it and i hope this blog can give you help in the same.
Have fun guys!!
