Spurious merge conflicts on publisher instance | Community
Skip to main content
K
kristofvb
Level 2
May 31, 2017
Solved

Spurious merge conflicts on publisher instance

  • May 31, 2017
  • 5 replies
  • 2046 views

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?

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by MC_Stuff

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,

5 replies

cquser1
cquser1
Level 7
May 31, 2017

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?

K
kristofvbAuthor
Level 2
May 31, 2017

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

MC_Stuff
MC_Stuff
Level 10
June 1, 2017

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,

    K
    kristofvbAuthor
    Level 2
    June 1, 2017

    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.

    MC_Stuff
    MC_StuffAccepted solution
    Level 10
    June 15, 2017

    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,

    Terms & ConditionsAccessibility statement

    Loading footer...