Incrementing Cluster Counts and Escaping Variables

This article explains the concepts of incrementing cluster variables per cluster member and how to set cluster specific numbering of cluster specific resources when using RapidDeploy for application release automation.


We need a mechanism to update log4j.xml files in deployed environments so that each cluster member has its own log4j.xml file. In this way logging can be set on a per clone basis and the rolling file appender will work correctly.


To do this we use a system property as follows:

In the python file we set the clusterIncrementer:

clusterIncrementer = 0

The actual first usage of this value is one more than the value set initially.

We then set the log4j system property:

systemProperties.append([["name", "log4j.configuration"], ["value", "\"/usr/websphere5/wassup5int/AppServer/installedApps/wassup5intNetwork/pandsapplicationInt.ear/config/lloydstsb/log4j/ICVALog_LiveSup\" + str(clusterIncrementer) + \".xml\""]])

(Standard system property):

systemProperties.append([["name", ""], ["value", "800"]])

Note how the string is entirely escaped using "\" abc \" +str(clusterIncrementer)+ \" def \"". This gets passed into wsadmin at runtime as "abc"+clusterIncrementer+"def". The clusterIncrementer variable can then be changed per cluster member and is not evaluated until used.

For a non escaped string "abc" +clusterIncrementer+ " def "" at runtime the value "abc0def" will get passed into wsadmin at runtime as the clusterIncrementer variable is evaluated immediately.

Note: Even if we do not have any value/text following "abc" +clusterIncrementer + "" we still need to escape the entire string and have empty escaped double quotes (") at the end as shown below to ensure the setting is evaluted correctly.

systemProperties.append([["name", "estatements.logs.dir"], ["value", "\"/usr/websphere6/wassup61_15/AppServer/logs/MVServerUAT01_clone\" + str(clusterIncrementer) + \"\"" ]])

SIB Endpoints

We need to set SIBproviderEndPoints as above if we have more than one cluster member on the same LPAR and the SIBJMSScopeType scope is set to "server":


SIBproviderEndPoints     = "localhost:"+str(SIB_ENDPOINT_ADDRESS_port)+":BootstrapBasicMessaging"


SIBproviderEndPoints     = "\"localhost:\"+str(SIB_ENDPOINT_ADDRESS)+\":BootstrapBasicMessaging\""

Note: The _port has been removed in the above because now we are getting the SIB_ENDPOINT_ADDRESS for each cluster member in the cluster prior to setting this variable.

Getting A Unique Value For A Port

There can be a problem using the clusterIncrementer for port values if the number of clones exceeds 9. For example if you have an application that requires each clone to listen on a unique port you could use the clusterIncrementer like this:

systemProperties.append([["name", "chordiant.service.socketGatewayServicePort"], ["value", "\"2602\" + str(clusterIncrementer)"]])

If you have initially set 'clusterIncrementer = 0' in the Jython file then this would set values of 26021, 26022, 26023 etc for the listener on each clone. The problem occurs on the 10th clone where the value would be set to 261210. The solution to this is to rescope the value are trying to set and then to set the clusterIncrementer value to one below the start of your range. So in this example we would set 'clusterIncrementer = 20' in the Jython file, then the above example would become�

systemProperties.append([["name", "chordiant.service.socketGatewayServicePort"], ["value", "\"260\" + str(clusterIncrementer)"]])

Note that '2602' has become '260'. Now the range of values will be 26021 � 26099. The range of values will be increased and decreased depending on the initial value of clusterIncrementer. It should also be noted that your existing usage of the clusterIncrementer elsewhere in your configuration should also be able to accommodate the change of range.