Hi all, I encountered the same issue mentioned with ESB 4.9.0 clustered setup. The worker node didn't start properly and produced the same error even for the second restart. Have we come across this scenario earlier?
The temporary solution was to replace the worker's server directory with that of the manager and restart the worker. Then the worker started properly and dep sync was working there after. On Sat, May 30, 2015 at 7:07 PM, Evanthika Amarasiri <evanth...@wso2.com> wrote: > Hi all, > > For products like ESB/API-M when we are replacing the packs with new ones, > we continuously see this behaviour while starting up the worker nodes. The > solution we have given is to clean the repo, start the server once, when > you get the exception '*The synapse.xml location > ././repository/deployment/server/synapse-configs/default doesn't exist*', > restart > the server once again. I'm wondering whether this the correct solution? > > Also, will we be seeing the same behaviour with Carbon 4.3.0 products as > well? > > Regards, > Evanthika > > On Thu, Dec 4, 2014 at 11:23 AM, Samuel Gnaniah <sam...@wso2.com> wrote: > >> Updated the note for API-M [1] and ESB [2] to include instructions to >> restart the server once again. >> >> [1] - https://docs.wso2.com/display/CLUSTER420/Clustering+the+Gateway >> [2] - https://docs.wso2.com/display/CLUSTER420/Clustering+ESB >> >> *Samuel Gnaniah* >> Senior Technical Writer >> >> WSO2 (pvt.) Ltd. >> Colombo, Sri Lanka >> (+94) 773131798 >> >> On Wed, Dec 3, 2014 at 12:03 PM, Evanthika Amarasiri <evanth...@wso2.com> >> wrote: >> >>> 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 > > -- Best Regards, Kalpa Welivitigoda Software Engineer, WSO2 Inc. http://wso2.com Email: kal...@wso2.com Mobile: +94776509215
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
