Expand my Community achievements bar.

SOLVED

Spurious merge conflicts on publisher instance

Avatar

Level 2

We are seeing spurious merge conflicts on publisher instances (AEM 6.1SP2) such as

merge-conflicts.log.2017-05-29:29.05.2017 09:20:09.437 *DEBUG* [172.18.27.44 [1496042409277] POST /bin/receive HTTP/1.1] org.apache.jackrabbit.oak.plugins.commit.ConflictValidator Commit failed due to unresolved conflicts in /content/dam/vrt/2017/02/23/wissper-r001-a0003-depot_WP00105034/jcr:content/vrt = {deleteChangedProperty = {cq:lastReplicated = {<N/A>,2017-05-29T09:20:09.093+02:00}}}

I suspect this is simply the replication agent trying to save some replicated asset as the stacktrace is showing

        ...

        at com.sun.proxy.$Proxy11.save(Unknown Source)

        at com.day.cq.replication.impl.content.durbo.DurboImporter.createNode(DurboImporter.java:295)

        at com.day.cq.replication.impl.content.durbo.DurboImporter.createNode(DurboImporter.java:215)

        at com.day.cq.replication.impl.ReplicationReceiverImpl.receive(ReplicationReceiverImpl.java:160)

        at com.day.cq.replication.impl.servlets.ReplicationServlet.doPost(ReplicationServlet.java:206)

I do not understand where the merge conflict is coming from. I am quite sure we do not have code that deletes the cq:lastReplicated property.

Does the replication agent use multiple threads and sessions to handle replicated items? Or any other theories as to what is causing this merge conflict?

1 Accepted Solution

Avatar

Correct answer by
Level 9

Hi kristofv82685890,

Chain replication is used to move into another environment without manual intervention. Since it is publish instance you might have configured after replication is complete from author to flush the dispatcher etc....   Out of the box stores the replication property only at jcr:content.   In your case it is jcr:content/vrt/cq: lastReplicated instead of jcr:content/cq: lastReplicated which indicates some customization done in pre processor & you need to verify the custom code Or third party code used here.  Again as you guessed jcr:content/vrt/cq: lastReplicated/cq:lastReplicated sounds to be custom code issue & practically you can;t have property within property.

P.S:-   Generally the thread I pick up try to answer any follow up question,  The new community feature of "listing based on creation user instead of last modified user" nor "the inbox feature"  is not friendly for an followup. If missed any followup please create a new thread.

Thanks,

View solution in original post

5 Replies

Avatar

Level 8

Hi,

Is this error specific to the file mentioned "/content/dam/vrt/2017/02/23/wissper-r001-a0003-depot_WP00105034/jcr:content"

or happening across all assets/pages?

Avatar

Level 2

It is not specific to one asset. The merge conflict occurs on other assets too.

Avatar

Level 9

Hi Kris,

Conflict may not be with replication module. There might be other module like workflow updating the same asset. In short two thread worked on same asset & first one wins. Last one fails.   Configure logger writer in trace level for class org.apache.jackrabbit.oak.jcr.operations.writes.  and verify which are those two threads.

Thanks,

Avatar

Level 2

Enabling the logger for org.apache.jackrabbit.oak.jcr.operations.writes shows me the following:

01.06.2017 17:47:23.563 *TRACE* [Adobe Granite ChainReplicationService Processor] org.apache.jackrabbit.oak.jcr.operations.writes [session-10639461] Setting property [/content/dam/vrt/2017/04/14/george-paul-p2014-a0020-depot_WP00084159/jcr:content/vrt/cq:lastReplicated]

01.06.2017 17:47:23.665 *TRACE* [172.18.27.44 [1496332043601] POST /bin/receive HTTP/1.1] org.apache.jackrabbit.oak.jcr.operations.writes [session-10639510] Removing property [/content/dam/vrt/2017/04/14/george-paul-p2014-a0020-depot_WP00084159/jcr:content/vrt/cq:lastReplicated/cq:lastReplicated]

The last log line is a bit strange (cq:lastReplicated/cq:lastReplicated should probably just be cq:lastReplicated).

So it looks like the replication servlet is removing the property while some processor is setting this property. I have no idea what the thread "Adobe Granite ChainReplicationService Processor" is for.

Does anyone have an idea what is going on?

Thanks.

Avatar

Correct answer by
Level 9

Hi kristofv82685890,

Chain replication is used to move into another environment without manual intervention. Since it is publish instance you might have configured after replication is complete from author to flush the dispatcher etc....   Out of the box stores the replication property only at jcr:content.   In your case it is jcr:content/vrt/cq: lastReplicated instead of jcr:content/cq: lastReplicated which indicates some customization done in pre processor & you need to verify the custom code Or third party code used here.  Again as you guessed jcr:content/vrt/cq: lastReplicated/cq:lastReplicated sounds to be custom code issue & practically you can;t have property within property.

P.S:-   Generally the thread I pick up try to answer any follow up question,  The new community feature of "listing based on creation user instead of last modified user" nor "the inbox feature"  is not friendly for an followup. If missed any followup please create a new thread.

Thanks,