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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected] >>> > wrote: >>> >>>> Yes. This is only for worker nodes. >>>> >>>> Regards, >>>> Evanthika >>>> >>>> On Wed, Dec 3, 2014 at 9:39 AM, Samuel Gnaniah <[email protected]> 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 <[email protected]> >>>>> 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 < >>>>>> [email protected]> 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 <[email protected]> >>>>>>> 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 < >>>>>>>> [email protected]> 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: [email protected] >>>>>>>> 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: [email protected] >>>>>> 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 >>>>>> [email protected] >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
