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
>
>
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
