El clúster de compilation del server de aplicaciones WSO2 sucede svn: el UUID del repository XXXX no coincide con el UUID esperado OOOO

Estoy probando WSO2 Application Server 5.2.1 + Load Balancer 2.1.1 en Ubuntu Server 14.04.2

A continuación está la configuration de mi entorno:

Java: OpenJDK-1.7

La versión del server SVN es 1.8

El nombre del repository SVN se llama "wso2"

Ahora creo un entorno de clúster de acuerdo con las instrucciones de Clustering Application Server .

Además de los pasos anteriores, también sigo la descripción de pasos a continuación en Deployment Synchronizer Configuration para la synchronization de SVN falla

Agregue los siguientes dos jar a 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

Agregue el siguiente file jar al repository / componente / dropins http://dist.wso2.org/maven2//org/tigris/svn-client-adapter/1.6.18.wso2v2/svn-client-adapter-1.6.18.wso2v2. tarro

Elb parece funcionar bien. pero el mgt (wso2ap3.uzoo.net) como sucede con las excepciones:

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 shanetworking 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 shanetworking 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) .... 

¿Cómo resolver la exception anterior?

Para todos los productos basados ​​en Carbon 4.2.xy siguientes, utilice únicamente SVN versión 1.6 para copys de trabajo (repositorys SVN agregados al sincronizador de implementación). Sin embargo, puede usar SVN 1.6 o 1.7 en sus serveres.

Los productos WSO2 basados ​​en Carbon 4.3.x (aún por lanzar) ofrecerán soporte para las versiones SVN 1.7 y 1.8.

No se admite el uso de SVN Deployment Synchronizer con protocolo SSH.

WSO2 Application Server 5.2.1 depende de Carbon 4.2.0, entonces, use SVN 1.6 o 1.7 para Server, y use SVN 1.6 para copys de trabajo.

Respuesta corta:

svnadmin setuuid REPOS_PATH [NEW_UUID]

Una respuesta un poco más larga:

Los repositorys de Subversion tienen un identificador único universal (UUID) asociado a ellos. Esto es utilizado por los clientes de Subversion para verificar la identidad de un repository cuando otras forms de verificación no son lo suficientemente buenas (como la verificación de la URL del repository, que puede cambiar con el time). La mayoría de los administradores de repositorys de Subversion rara vez, o nunca, deben pensar en los UUID de repository como algo más que un detalle de implementación trivial de Subversion. A veces, sin embargo, hay motivos para prestar atención a este detalle.

Como regla general, desea que los UUID de sus repositorys activos sean únicos. Eso es, después de todo, el punto de tener UUIDs. Pero hay ocasiones en que desea que los UUID del repository de dos repositorys sean exactamente iguales. Por ejemplo, si realiza una copy de un repository con fines de copy de security, desea que la copy de security sea una réplica perfecta del original, de modo que, en caso de que tenga que restaurar esa copy de security y replace el repository activo, los usuarios no lo hagan. De repente veo lo que parece un repository diferente . Al download y cargar el historial del repository (como se describió anteriormente en la sección llamada "Migración de datos del repository en otro lugar"), puede decidir si aplica el UUID encapsulado en la secuencia de volcado de datos al depósito en el que está cargando los datos. La circunstancia particular dictará el comportamiento correcto.

Hay un par de forms de configurar (o restablecer) el UUID de un repository, si es necesario. A partir de Subversion 1.5, esto es tan simple como usar el command svnadmin setuuid. Si proporciona este subcommand con un UUID explícito, validará que el UUID está bien formado y luego establecerá el UUID del repository en ese valor. Si omite el UUID, se generará un nuevo UUID para su repository.

    Intereting Posts