Cluster Synchronization Exceptions

Cluster synchronization exceptions are reported after shutting down the primary Unwired Server.

Problem: This typically happens after shutting down the primary Unwired Server, soon after performing a cluster-changing operation [such as updating the Schedule property for a Mobile Business Object (MBO)]. The shut down occurs before any of the secondary servers received the updated clusterdata.zip file. The secondary severs detect the version difference in the clusterdata.zip files, shuts down RSOE, and issues an HTTP GET to download the newer file version. Since the primary server was shutdown, the file cannot be downloaded, a secondary cluster cannot become the primary, and cluster sync exceptions are reported in the ML.log file in this format:

ML.log 
====== 
 E. 2009-06-22 10:09:56. < Main > [-10133] SEVERE: This SUP cluster member is
at version 14 while the cluster is at version 15
I. 2009-06-22 10:09:59. < Main > The primary server in the server farm is now:
'GOLDENGATESUPServer3'
I. 2009-06-22 10:09:59. < Main > < SISI > < SISManager > : This is a secondary
MobiLink server
E. 2009-06-22 10:10:00. < Main > [-10133] Jun 22, 2009 10:10:00 AM
com.sybase.ep.utils.ClusterUtils$1 invoke
E. 2009-06-22 10:10:00. < Main > [-10133] SEVERE: This SUP cluster member is
at version 14 while the cluster is at version 15
E. 2009-06-22 10:10:00. < Main > [-10133] Jun 22, 2009 10:10:00 AM
com.sybase.ep.utils.ClusterUtils isVersionCorrect

Workaround:If the primary Unwired Server cannot be restarted, you can fix the broken cluster manually:

Shut down the primary Unwired Server.
Copy across the clusterdata. < version > .zip.
Edit sup.properties manually to set cluster.version and sup.cluster.version to the new value (for this example, this value would be 15).
Run updateProps -r to load the new version information into the clusterdb.
Run updateFiles to unzip the clusterdata.zip.
Start Unwired Server. Since its version now matches the cluster version in clusterdb, it will take over as the primary server.
Any other secondary servers that are still trying to sync will detect the new primary server and will initiate the HTTP GET for the clusterdata.zip from the new primary server.