[SOLVED] Can't make replication service work

[fr3dy]

Hi. I'm trying to replicate one Alfresco Community 4.0d installation from one site to another, but I'm having problems configuring it (and finding documentation).
Both sites have only the default content, except the source node which contains a test site too (it should be replicated on the other).

I did the following:

- Added "replication.enabled=true" in alfresco-global.properties (both alfresco instances)

- Defined a "primaryStore" pointing to /app/alfresco-4.0.d/alf_data/contentstore in replicating-content-services-context.xml (source node only)

- Added share url in the source alfresco with those contents in share-config-custom.xml: (source node only)

   …
    <config evaluator="string-compare" condition="Replication">
   …
        <share-url repositoryId="remote_alfresco_ID_obtained_from_CMIS_info">http://remote_target_alfresco/share/</share-url>
   …‍‍‍‍‍

- Created new folder under Repository / Data Dictionary / Transfers / Transfer Targets / Default group, pointing to the target alfresco (source node only)

- Created a new replicating job In Admin Tools / Replication Jobs, targeting the previous folder (source node only)


When I click on 'Run Job', I got this exception on the target node:

2012-04-23 09:59:39,844  ERROR [repo.transaction.AlfrescoTransactionSupport] [defaultAsyncAction1] After completion (rolled-back) listener exception:
   listener: org.alfresco.repo.transfer.TransferCommitTransactionListener@12731ffa
 java.lang.NullPointerException
        at org.alfresco.repo.content.replication.ReplicatingContentStore$ReplicatingWriteListener$ReplicateOnCloseRunnable.run(ReplicatingContentStore.java:437)
        at org.alfresco.repo.content.replication.ReplicatingContentStore$ReplicatingWriteListener.contentStreamClosedImpl(ReplicatingContentStore.java:420)
…
…
2012-04-23 09:59:39,849  ERROR [content.cleanup.EagerContentStoreCleaner] [defaultAsyncAction1] Content deletion failed:
   URL:    store://2012/4/23/9/59/32128378-02b2-40e6-889b-0c66f91b4bf9.bin
   Source: org.alfresco.repo.content.replication.ReplicatingContentStore@399e2cb3
 java.lang.NullPointerException
        at org.alfresco.repo.content.replication.ReplicatingContentStore.delete(ReplicatingContentStore.java:344)
        at org.alfresco.repo.content.cleanup.EagerContentStoreCleaner.deleteFromStore(EagerContentStoreCleaner.java:306)
…
…
2012-04-23 09:59:40,051  ERROR [repo.action.AsynchronousActionExecutionQueueImpl] [defaultAsyncAction1] Failed to execute asynchronous action: Action[ id=ee84bb62-6d7a-4715-b87a-757f77dc0b9d, node=null ]
 org.alfresco.repo.transfer.TransferFatalException: 03230004 An error has occurred while trying to commit transfer {0}
        at org.alfresco.repo.transfer.AbstractManifestProcessorBase.handleException(AbstractManifestProcessorBase.java:224)
…
Caused by: java.lang.NullPointerException
        at org.alfresco.repo.content.replication.ReplicatingContentStore$ReplicatingWriteListener$ReplicateOnCloseRunnable.run(ReplicatingContentStore.java:437)
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I couldn't find any doc. or example about configuring it from the start.
Could anybody help?


Thanks.

[afaust]

Hello,

based on your log output you have configured a replicating content store on the target node as well (your list specifically states this as "source node" only). Please be aware that for content replication between Alfresco instances you do not need any replicating content store. The replicating content store is only relevant for distributing content of one instance on several backend storage systems.

Please adapt your configuration and try again without the replicating stores. When content replication works in general, you should investigate the error from the replicating content store which I assume is caused by something else in your configuration / setup.

Regards
Axel

[fr3dy]

I've renamed the file replicating-content-services-context.xml to disable it on both nodes (you were right, I enabled it on both instances).
After restarting services…. IT WORKS! I'm gonna make some tests now.

By the way, is it possible to configure Active-Passive nodes by using replication? I mean, enable transfer from instance 1–>2 and, if instance 1 fails, activate 2–>1 (automatized if possible).


Thanks for your reply!

[afaust]

Hello,

technically, something like this would be possible with implementation, but there could be a variety of complications. For one, the version history and versionable policy is only stored on the originating node (say "1") and not transferred to the replication target. The replicated node on "2" is not versionable by default and even if you enabled versioning for it, you would end up with two distinct histories if you reverse the replication direction.

Regards
Axel

[fr3dy]

Hello,

technically, something like this would be possible with implementation, but there could be a variety of complications. For one, the version history and versionable policy is only stored on the originating node (say "1") and not transferred to the replication target. The replicated node on "2" is not versionable by default and even if you enabled versioning for it, you would end up with two distinct histories if you reverse the replication direction.

Regards
Axel

So, what are the chances of using a replicated instance as primary one? Should I do something like this?:

1) Replicate from alf1 to alf2

2) If alf1 fails, use alf2 (read-only) while fixing/restoring alf1

3) Once restored, enable alf1 again and continue from step 1)

I guess enabling read-write on alf2 is not a good idea, since it should always be a mirror of the main node (alf1). Could you confirm this and the above?



Thanks a lot for your help

[afaust]

Hello,

for the most common scenario of a temporary downtime of alf1 I would advise to follow the points you've listed.
Switching the "primary node" in a replication context should only be used if it fulfills a business use case - not for purely technical reasons. It should at all times be clear which node stores the master and what nodes only manage the mirror nodes - including the additional data that accompanies the master. So as long as you do not have the functionality in place that transfers this additional data, the node on alf2 can and should only ever be a mirror.

Regards
Axel

[fr3dy]

Hello,

for the most common scenario of a temporary downtime of alf1 I would advise to follow the points you've listed.
Switching the "primary node" in a replication context should only be used if it fulfills a business use case - not for purely technical reasons. It should at all times be clear which node stores the master and what nodes only manage the mirror nodes - including the additional data that accompanies the master. So as long as you do not have the functionality in place that transfers this additional data, the node on alf2 can and should only ever be a mirror.

Regards
Axel

I'll do that then. Thanks!!!