I will also add to osqa the issue with the "Axis Module not found". I
recently saw this same error [1] for a customer case, so it is not an
isolated thing. A restart is an adequate workaround.
-Colin
[1] TID: [0] [AM] [2015-02-04 14:30:20,522] ERROR
{org.wso2.carbon.core.persistence.AbstractPersistenceManager} - Unable to
handle service initialization. Service: WorkflowCallbackService
{org.wso2.carbon.core.persistence.AbstractPersistenceManager}
org.wso2.carbon.CarbonException: Axis Module not found for :
wso2statistics-4.2.2
at
org.wso2.carbon.core.persistence.AbstractPersistenceManager.getExistingAxisModule(AbstractPersistenceManager.java:562)
at
org.wso2.carbon.core.persistence.ServicePersistenceManager.handleExistingServiceInit(ServicePersistenceManager.java:472)
at
org.wso2.carbon.core.deployment.DeploymentInterceptor.serviceUpdate(DeploymentInterceptor.java:298)
Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile* : 812-219-6517
On Thu, Dec 4, 2014 at 12:53 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
>
>
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
