WSO2 Application Server build cluster happens svn: Repository UUID XXXX doesn't match expected UUID OOOO

Question

I am testing WSO2 Application Server 5.2.1 + Load Balancer 2.1.1 in Ubuntu Server 14.04.2

Below is my environment configuration:

Java:OpenJDK-1.7

SVN Server version is 1.8

The SVN repository name is called "wso2"

I now build a cluster environment according to the instructions in Clustering Application Server.

In additional the above steps, I also follow below steps descriping in Deployment Synchronizer Configuration for SVN sync fails

Add following two jar to repository/component/lib http://mirrors.ibiblio.org/pub/mirrors/maven2/org/tmatesoft/svnkit/svnkit/1.3.5/svnkit-1.3.5.jar http://mirrors.ibiblio.org/pub/mirrors/maven2/org/tmatesoft/svnkit/svnkit-javahl/1.3.5/svnkit-javahl-1.3.5.jar

Add following jar to repository/component/dropins http://dist.wso2.org/maven2//org/tigris/svn-client-adapter/1.6.18.wso2v2/svn-client-adapter-1.6.18.wso2v2.jar

The elb seems to run OK. but the mgt(wso2ap3.uzoo.net) as happens to exceptions:

TID: [0] [AS] [2015-05-11 11:19:50,493]  INFO {org.wso2.carbon.core.clustering.hazelcast.HazelcastClusteringAgent} -  Local member: [b1c58ff3-9472-4f6c-b5e8-9eb4e34a1d68] - Host:192.168.168.220, Remote Host:null, Port: 4250, HTTP:9764, HTTPS:9444, Domain: wso2.as.domain, Sub-domain:mgt, Active:true {org.wso2.carbon.core.clustering.hazelcast.HazelcastClusteringAgent}
TID: [0] [AS] [2015-05-11 11:19:50,498]  INFO {org.wso2.carbon.core.clustering.hazelcast.util.MemberUtils} -  Added member: Host:192.168.168.220, Remote Host:null, Port: 4250, HTTP:9764, HTTPS:9444, Domain: wso2.as.domain, Sub-domain:mgt, Active:true {org.wso2.carbon.core.clustering.hazelcast.util.MemberUtils}
TID: [0] [AS] [2015-05-11 11:19:50,624]  INFO {org.wso2.carbon.core.clustering.hazelcast.HazelcastClusteringAgent} -  Cluster initialization completed {org.wso2.carbon.core.clustering.hazelcast.HazelcastClusteringAgent}
TID: [0] [AS] [2015-05-11 11:19:50,626]  INFO {org.apache.tomcat.util.net.NioSelectorPool} -  Using a shared selector for servlet write/read {org.apache.tomcat.util.net.NioSelectorPool}
TID: [0] [AS] [2015-05-11 11:19:50,683]  INFO {org.apache.tomcat.util.net.NioSelectorPool} -  Using a shared selector for servlet write/read {org.apache.tomcat.util.net.NioSelectorPool}
TID: [0] [AS] [2015-05-11 11:19:50,722]  INFO {org.wso2.carbon.ntask.core.service.impl.TaskServiceImpl} -  Task service starting in CLUSTERED mode... {org.wso2.carbon.ntask.core.service.impl.TaskServiceImpl}
TID: [0] [AS] [2015-05-11 11:19:51,115]  INFO {org.wso2.carbon.core.init.JMXServerManager} -  JMX Service URL  : service:jmx:rmi://localhost:11112/jndi/rmi://localhost:10000/jmxrmi {org.wso2.carbon.core.init.JMXServerManager}
TID: [0] [AS] [2015-05-11 11:19:51,116]  INFO {org.wso2.carbon.core.internal.StartupFinalizerServiceComponent} -  Server           :  Application Server-5.2.1 {org.wso2.carbon.core.internal.StartupFinalizerServiceComponent}
TID: [0] [AS] [2015-05-11 11:19:51,117]  INFO {org.wso2.carbon.core.internal.StartupFinalizerServiceComponent} -  WSO2 Carbon started in 18 sec {org.wso2.carbon.core.internal.StartupFinalizerServiceComponent}
TID: [0] [AS] [2015-05-11 11:19:51,258]  INFO {org.wso2.carbon.ui.internal.CarbonUIServiceComponent} -  Mgt Console URL  : https://wso2ap3.uzoo.net:8243/carbon/ {org.wso2.carbon.ui.internal.CarbonUIServiceComponent}
TID: [0] [AS] [2015-05-11 11:20:00,101] ERROR {org.wso2.carbon.deployment.synchronizer.subversion.SVNBasedArtifactRepository} -  Error while checking out or updating artifacts from the SVN repository {org.wso2.carbon.deployment.synchronizer.subversion.SVNBasedArtifactRepository}
org.tigris.subversion.svnclientadapter.SVNClientException: org.tigris.subversion.javahl.ClientException: svn: Repository UUID '025b8c78-f788-11e4-9b42-0b9417c5a686' doesn't match expected UUID '0055e058-f55e-11e4-936c-e97121446169'
        at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.update(AbstractJhlClientAdapter.java:1079)
        at org.wso2.carbon.deployment.synchronizer.subversion.SVNBasedArtifactRepository.checkout(SVNBasedArtifactRepository.java:440)
        at org.wso2.carbon.deployment.synchronizer.internal.DeploymentSynchronizer.checkout(DeploymentSynchronizer.java:181)
        at org.wso2.carbon.deployment.synchronizer.internal.DeploymentSynchronizerServiceImpl.update(DeploymentSynchronizerServiceImpl.java:87)
        at org.wso2.carbon.core.deployment.CarbonDeploymentSchedulerTask.deploymentSyncUpdate(CarbonDeploymentSchedulerTask.java:165)
        at org.wso2.carbon.core.deployment.CarbonDeploymentSchedulerTask.run(CarbonDeploymentSchedulerTask.java:123)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)
....

How to solve the above exception?

Answer 1

For all products based on Carbon 4.2.x and below, please use only SVN version 1.6 for working copies (SVN repositories added to the deployment synchronizer). However, you can use SVN 1.6 or 1.7 on your servers.

WSO2 products that are based on Carbon 4.3.x (yet to be released) will offer support for SVN versions 1.7 and 1.8.

Using SVN Deployment Synchronizer with SSH protocol is not supported.

WSO2 Application Server 5.2.1 depends on Carbon 4.2.0, So, please use SVN 1.6 or 1.7 for Server, and use SVN 1.6 for working copies.

Answer 2

Short answer:

svnadmin setuuid REPOS_PATH [NEW_UUID]

A bit longer answer:

Subversion repositories have a universally unique identifier (UUID) associated with them. This is used by Subversion clients to verify the identity of a repository when other forms of verification aren't good enough (such as checking the repository URL, which can change over time). Most Subversion repository administrators rarely, if ever, need to think about repository UUIDs as anything more than a trivial implementation detail of Subversion. Sometimes, however, there is cause for attention to this detail.

As a general rule, you want the UUIDs of your live repositories to be unique. That is, after all, the point of having UUIDs. But there are times when you want the repository UUIDs of two repositories to be exactly the same. For example, if you make a copy of a repository for backup purposes, you want the backup to be a perfect replica of the original so that, in the event that you have to restore that backup and replace the live repository, users don't suddenly see what looks like a different repository. When dumping and loading repository history (as described earlier in the section called “Migrating Repository Data Elsewhere”), you get to decide whether to apply the UUID encapsulated in the data dump stream to the repository in which you are loading the data. The particular circumstance will dictate the correct behavior.

There are a couple of ways to set (or reset) a repository's UUID, should you need to. As of Subversion 1.5, this is as simple as using the svnadmin setuuid command. If you provide this subcommand with an explicit UUID, it will validate that the UUID is well-formed and then set the repository UUID to that value. If you omit the UUID, a brand-new UUID will be generated for your repository.