AEM 6.3: Author -> dispatcher flush also executes replication event to publishers | Community
Skip to main content
J
JeroenDruwe
Level 4
January 16, 2019

AEM 6.3: Author -> dispatcher flush also executes replication event to publishers

  • January 16, 2019
  • 2 replies
  • 9726 views

Let me first describe our 2 agents on our author environment:

- Dispatcher flush agent (we have a dispatcher in front of our author environment to add an extra layer of caching for the content authors)

- Default agent (used for publishing to the publish environment)

NOTE: obviously 2 different entities.

The dispatcher flush agent is new in our setup and gets trigger on modification. After adding the agent our content author complained that their changes were automatically published for some reason. After some investigation/debugging of the com.day.cq.replication.impl.ReplicatorImpl it seems that there is also a replication event fired by the RolloutManager with the following ReplicationOptions (note: no AgentIdFilter or ReplicateOnModification filter)

ReplicationOptions{synchronous=false, revision='null', suppressStatusUpdate=false, suppressVersions=false, filter=null, aggregateHandler=null}

No filter results in all enabled agents to be triggered so the path will get replicated to the publishers, NOT wat we want...

It seems to me the the combination of a dispatcher flush agent and default agent is not working properly. Anyone experiencing the same problems?

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

2 replies

Gaurav-Behl
Gaurav-Behl
Level 10
January 16, 2019

Since the flush agent is on author, could you validate that the "Triggers" tab of the flush agent doesn't have any checkbox turned on esp. Ignore Default or On Modification?

Are you doing programmatic replication/flushing or any workflow based replication/flushing of the content using ReplicationOptions?

    J
    JeroenDruweAuthor
    Level 4
    January 17, 2019

    This is our triggers tab:
    And no workflows are doing such a thing in our codebase at the moment. Wouldn't I see our custom class if we had one when debugging?

      joerghoh
      Adobe Employee
      joerghohAdobe Employee
      Adobe Employee
      January 16, 2019

      In any case, the RolloutManager would always fire a replication event if it's configured in that way; it does not depend on the fact if a flush agent is configured or not (or even a combination of standard replication agent and flush agent).

      I assume that it's just a coincidence of these 2 activities, and that the flush agent has nothing to do with it. Have you changed your rollout configuration recently to include replication?

      Jörg

        J
        JeroenDruweAuthor
        Level 4
        January 17, 2019

        I am testing it on a local machine with a default and dispatcher flush agent pointing to our acceptance env. so it would can't be a coincidence because I see it every time and I am the only one testing on my local machine. We have the following rollout configs on our livecopy:

        - /etc/msm/rolloutconfigs/pushonmodify
        - /etc/msm/rolloutconfigs/activate
        - /etc/msm/rolloutconfigs/deactivate

        We had the above config from the start of the project and never had any pages publish automatically on edit. We only want the dispatcher flush on edit for now.

          J
          JeroenDruweAuthor
          Level 4
          January 23, 2019

          Editing a component -

          pushonmodify rollout pushed the content changes from source to live copies and then generated 'onmodify' event which was captured by flush agent and hence you see two invalidation requests with 'replication-service' triggered by flush agent.

          I'm not sure why 'webservice-support-replication' got triggered for the child pages. Here's the explanation & fix for same [1]. Now 'msm-service' publish and invalidation request got triggered from the 'onmodify' trigger that was launched by 'pushonmodify' rollout. I believe this is what you mentioned as the problem statement. I'm not sure if this is a bug or expected functionality.

          On publish-

          Since admin user triggered the publish hence the first row is fine. In this case 'webservice-support-replication' [1] still got triggered. The rows with 'msm-service' are fine as it was a publish + invalidation request.

          [1] - Flush replications are triggered by webservice-support-replication user | AEM 6.x

          Per my knowledge, the common listener for publish agent and invalidation agent doesn't distinguish the action to be taken if the filter agent is null (which is the case here for onmodify event). Probably Jörg Hoh can help here..

          The stack trace for 'Thread-1349' might be waiting on the agent itself because the queue was blocked.


          "Now 'msm-service' publish and invalidation request got triggered from the 'onmodify' trigger that was launched by 'pushonmodify' rollout. I believe this is what you mentioned as the problem statement. I'm not sure if this is a bug or expected functionality." Indeed I am not sure as well :S

            Terms & ConditionsAccessibility statement

            Loading footer...