This note is applicable for products like AS/BPS/etc. But for products like API-M & ESB, the first time you restart the server after cleaning the *server* folder will throw the exception - '*The synapse.xml location ././repository/deployment/server/synapse-configs/default doesn't exist*'.
So to resolve that, you have to restart the server once again. We need to find a proper solution for that. Regards, Evanthika Amarasiri Senior Technical Lead - Quality Assurance Mobile: +94773125935 Blog: evanthika.blogspot.com wso2.com lean.enterprise.middleware On Wed, Dec 3, 2014 at 11:53 AM, Samuel Gnaniah <sam...@wso2.com> wrote: > Added a small note on this in [1], [2] and [3]. Thanks for bringing this > up! > > [1] - https://docs.wso2.com/display/CLUSTER420/Configuring+the+Worker+Node > [2] - > https://docs.wso2.com/display/CLUSTER420/Clustering+WSO2+Products+without+WSO2+ELB > [3] - https://docs.wso2.com/display/CLUSTER420/Clustering+the+Gateway > > Thanks, > Sam > > *Samuel Gnaniah* > Senior Technical Writer > > WSO2 (pvt.) Ltd. > Colombo, Sri Lanka > (+94) 773131798 > > On Wed, Dec 3, 2014 at 11:35 AM, Evanthika Amarasiri <evanth...@wso2.com> > wrote: > >> Yes. This is only for worker nodes. >> >> Regards, >> Evanthika >> >> On Wed, Dec 3, 2014 at 9:39 AM, Samuel Gnaniah <sam...@wso2.com> wrote: >> >>> Just to confirm, are we recommending this only in the worker nodes? >>> >>> *Samuel Gnaniah* >>> Senior Technical Writer >>> >>> WSO2 (pvt.) Ltd. >>> Colombo, Sri Lanka >>> (+94) 773131798 >>> >>> On Wed, Dec 3, 2014 at 8:34 AM, Sameera Jayasoma <same...@wso2.com> >>> wrote: >>> >>>> Even for Carbon 4.3.0 testing, we followed the same method. We will try >>>> to fix these errors during the AS 6.0.0 release. But for 4.2.0 based >>>> products, lets document this step. >>>> >>>> Thanks, >>>> Sameera. >>>> >>>> >>>> On Wed, Dec 3, 2014 at 7:47 AM, Evanthika Amarasiri <evanth...@wso2.com >>>> > wrote: >>>> >>>>> Yes Sameera, I got this continuously on >>>>> >>>>> API-M worker nodes yesterday. So, after this SVN error, I see >>>>> another exception with regard to service initialisation due to a missing >>>>> module as below. >>>>> >>>>> So I suppose there are can be functionality breaks once you get this >>>>> svn issue. Anyhow, throwing such ERRORs at startup is not right. So if >>>>> these are harmless errors we can make them warnings instead without >>>>> printing a whole stack trace like this? >>>>> >>>>> However, in this case, what I feel is that there can be functionality >>>>> issues. I will investigate on this further. >>>>> >>>>> Also, if this is what we recommend to users (removing the content >>>>> inside the server folder before starting worker nodes), shall we add this >>>>> to our documentation? >>>>> >>>>> >>>>> TID: [0] [AM] [2014-12-02 06:30:15,390] ERROR >>>>> {org.wso2.carbon.core.persistence.AbstractPersistenceManager} - Unable to >>>>> handle service initialization. Service: WSRegistryService >>>>> {org.wso2.carbon.core.persistence.AbstractPersistenceManager} >>>>> org.wso2.carbon.CarbonException: *Axis Module not found for : >>>>> addressing-4.2.0* >>>>> at >>>>> org.wso2.carbon.core.persistence.AbstractPersistenceManager.getExistingAxisModule(AbstractPersistenceManager.java:583) >>>>> at >>>>> org.wso2.carbon.core.persistence.ServicePersistenceManager.handleExistingServiceInit(ServicePersistenceManager.java:469) >>>>> at >>>>> org.wso2.carbon.core.persistence.file.deployer.PersistenceMetaDataDeployer.deploy(PersistenceMetaDataDeployer.java:96) >>>>> at >>>>> org.apache.axis2.deployment.repository.util.DeploymentFileData.deploy(DeploymentFileData.java:136) >>>>> at >>>>> org.apache.axis2.deployment.DeploymentEngine.doDeploy(DeploymentEngine.java:807) >>>>> at >>>>> org.apache.axis2.deployment.repository.util.WSInfoList.update(WSInfoList.java:144) >>>>> at >>>>> org.apache.axis2.deployment.RepositoryListener.update(RepositoryListener.java:377) >>>>> at >>>>> org.apache.axis2.deployment.RepositoryListener.checkServices(RepositoryListener.java:254) >>>>> at >>>>> org.apache.axis2.deployment.RepositoryListener.startListener(RepositoryListener.java:371) >>>>> at >>>>> org.apache.axis2.deployment.scheduler.SchedulerTask.checkRepository(SchedulerTask.java:59) >>>>> at >>>>> org.apache.axis2.deployment.scheduler.SchedulerTask.run(SchedulerTask.java:67) >>>>> at >>>>> org.wso2.carbon.core.deployment.CarbonDeploymentSchedulerTask.runAxisDeployment(CarbonDeploymentSchedulerTask.java:79) >>>>> at >>>>> org.wso2.carbon.core.deployment.CarbonDeploymentSchedulerTask.run(CarbonDeploymentSchedulerTask.java:124) >>>>> 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) >>>>> TID: [0] [AM] [2014-12-02 06:30:15,391] ERROR >>>>> {org.wso2.carbon.core.persistence.file.deployer.PersistenceMetaDataDeployer} >>>>> - Unable to handle service initialization. Service: WSRegistryService >>>>> {org.wso2.carbon.core.persistence.file.deployer.PersistenceMetaDataDeployer} >>>>> org.wso2.carbon.core.persistence.PersistenceException: Unable to >>>>> handle service initialization. Service: WSRegistryService >>>>> at >>>>> org.wso2.carbon.core.persistence.AbstractPersistenceManager.handleExceptionWithRollback(AbstractPersistenceManager.java:603) >>>>> at >>>>> org.wso2.carbon.core.persistence.ServicePersistenceManager.handleExistingServiceInit(ServicePersistenceManager.java:744) >>>>> at >>>>> org.wso2.carbon.core.persistence.file.deployer.PersistenceMetaDataDeployer.deploy(PersistenceMetaDataDeployer.java:96) >>>>> at >>>>> org.apache.axis2.deployment.repository.util.DeploymentFileData.deploy(DeploymentFileData.java:136) >>>>> at >>>>> org.apache.axis2.deployment.DeploymentEngine.doDeploy(DeploymentEngine.java:807) >>>>> at >>>>> org.apache.axis2.deployment.repository.util.WSInfoList.update(WSInfoList.java:144) >>>>> at >>>>> org.apache.axis2.deployment.RepositoryListener.update(RepositoryListener.java:377) >>>>> at >>>>> org.apache.axis2.deployment.RepositoryListener.checkServices(RepositoryListener.java:254) >>>>> at >>>>> org.apache.axis2.deployment.RepositoryListener.startListener(RepositoryListener.java:371) >>>>> at >>>>> org.apache.axis2.deployment.scheduler.SchedulerTask.checkRepository(SchedulerTask.java:59) >>>>> at >>>>> org.apache.axis2.deployment.scheduler.SchedulerTask.run(SchedulerTask.java:67) >>>>> at >>>>> org.wso2.carbon.core.deployment.CarbonDeploymentSchedulerTask.runAxisDeployment(CarbonDeploymentSchedulerTask.java:79) >>>>> at >>>>> org.wso2.carbon.core.deployment.CarbonDeploymentSchedulerTask.run(CarbonDeploymentSchedulerTask.java:124) >>>>> 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) >>>>> Caused by: org.wso2.carbon.CarbonException: Axis Module not found for >>>>> : addressing-4.2.0 >>>>> at >>>>> org.wso2.carbon.core.persistence.AbstractPersistenceManager.getExistingAxisModule(AbstractPersistenceManager.java:583) >>>>> at >>>>> org.wso2.carbon.core.persistence.ServicePersistenceManager.handleExistingServiceInit(ServicePersistenceManager.java:469) >>>>> ... 18 more >>>>> >>>>> Regards, >>>>> Evanthika >>>>> >>>>> >>>>> On Tuesday, December 2, 2014, Sameera Jayasoma <same...@wso2.com> >>>>> wrote: >>>>> >>>>>> If you unzip a fresh pack and configure svn depsync with an already >>>>>> populated svn repository, then you will see such errors. I believe these >>>>>> are harmless errors. Evanthika, do you get these errors every time you >>>>>> restart? Also does this break any functionality? >>>>>> >>>>>> Our recommendation is to delete the repository/deployment/server >>>>>> directory and create an empty server directory. This way we can avoid svn >>>>>> conflicts etc. We've been recommending this approach to users. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Sameera. >>>>>> >>>>>> On Tue, Dec 2, 2014 at 6:17 PM, Evanthika Amarasiri < >>>>>> evanth...@wso2.com> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> While testing API-M 1.8.0, I noticed the following exception on all >>>>>>> gateway worker nodes. >>>>>>> >>>>>>> TID: [0] [AM] [2014-12-02 07:02:05,108] 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: Failed to add >>>>>>> directory >>>>>>> 'modulemetafiles': an unversioned directory of the same name already >>>>>>> exists >>>>>>> at >>>>>>> org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.checkout(AbstractJhlClientAdapter.java:297) >>>>>>> at >>>>>>> org.wso2.carbon.deployment.synchronizer.subversion.SVNBasedArtifactRepository.checkout(SVNBasedArtifactRepository.java:419) >>>>>>> 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) >>>>>>> Caused by: org.tigris.subversion.javahl.ClientException: svn: Failed >>>>>>> to add directory 'modulemetafiles': an unversioned directory of the same >>>>>>> name already exists >>>>>>> at >>>>>>> org.tigris.subversion.javahl.JavaHLObjectFactory.throwException(JavaHLObjectFactory.java:777) >>>>>>> at >>>>>>> org.tmatesoft.svn.core.javahl.SVNClientImpl.throwException(SVNClientImpl.java:1850) >>>>>>> at >>>>>>> org.tmatesoft.svn.core.javahl.SVNClientImpl.checkout(SVNClientImpl.java:1976) >>>>>>> at >>>>>>> org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.checkout(AbstractJhlClientAdapter.java:287) >>>>>>> ... 12 more >>>>>>> Caused by: org.tmatesoft.svn.core.SVNException: svn: Failed to add >>>>>>> directory 'modulemetafiles': an unversioned directory of the same name >>>>>>> already exists >>>>>>> at >>>>>>> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) >>>>>>> at >>>>>>> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) >>>>>>> at >>>>>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:623) >>>>>>> at >>>>>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:274) >>>>>>> at >>>>>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:262) >>>>>>> at >>>>>>> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:266) >>>>>>> at >>>>>>> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1261) >>>>>>> at >>>>>>> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:818) >>>>>>> at >>>>>>> org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:558) >>>>>>> at >>>>>>> org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:934) >>>>>>> at >>>>>>> org.tmatesoft.svn.core.javahl.SVNClientImpl.checkout(SVNClientImpl.java:1973) >>>>>>> ... 13 more >>>>>>> >>>>>>> After discussing with the Carbon team, found out that the solution >>>>>>> is to delete the *$API_HOME/repository/deployment/server* folder >>>>>>> the first time you start the server. This works for products like >>>>>>> AS/DSS/BPS,etc. >>>>>>> >>>>>>> However, for products like API-M, ESB, the first time you start the >>>>>>> server, it will throw the exception '*The synapse.xml location >>>>>>> ././repository/deployment/server/synapse-configs/default doesn't >>>>>>> exist*'. >>>>>>> The solution right now is to restart the server which IMO is not a >>>>>>> correct >>>>>>> solution and should be handled in some other way. >>>>>>> >>>>>>> We have come across this issue with almost all the products and have >>>>>>> reported the same many times. So I suppose it's time we finalize on this >>>>>>> solution and document it. >>>>>>> >>>>>>> @Sameera, appreciate your feedback on this. >>>>>>> >>>>>>> Regards, >>>>>>> Evanthika Amarasiri >>>>>>> Senior Technical Lead - Quality Assurance >>>>>>> Mobile: +94773125935 >>>>>>> Blog: evanthika.blogspot.com >>>>>>> >>>>>>> wso2.com lean.enterprise.middleware >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sameera Jayasoma, >>>>>> Software Architect, >>>>>> >>>>>> WSO2, Inc. (http://wso2.com) >>>>>> email: same...@wso2.com >>>>>> blog: http://sameera.adahas.org >>>>>> twitter: https://twitter.com/sameerajayasoma >>>>>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >>>>>> Mobile: 0094776364456 >>>>>> >>>>>> Lean . Enterprise . Middleware >>>>>> >>>>>> >>>> >>>> >>>> -- >>>> Sameera Jayasoma, >>>> Software Architect, >>>> >>>> WSO2, Inc. (http://wso2.com) >>>> email: same...@wso2.com >>>> blog: http://sameera.adahas.org >>>> twitter: https://twitter.com/sameerajayasoma >>>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >>>> Mobile: 0094776364456 >>>> >>>> Lean . Enterprise . Middleware >>>> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> Dev@wso2.org >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >> >
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
